Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Technical Discussion (http://www.chiefdelphi.com/forums/forumdisplay.php?f=22)
-   -   Philosophies on design reuse (http://www.chiefdelphi.com/forums/showthread.php?t=110343)

ToddF 02-01-2013 14:01

Philosophies on design reuse
 
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.

Quote:

Originally Posted by apalrd (Post 1206503)
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.


BigJ 02-01-2013 14:16

Re: Philosophies on design reuse
 
I'm not entirely sure why it hasn't yet, but designs should really move over the the software reuse rules with the caveat that no physical fabrication used on the competition robot is done prior to kickoff.

The software reuse rules are (generally) that you may reuse your software/algorithms as long as they are openly available to others.

(Offtopic: I think you intended to edit your original post but made a new topic instead :) )

nathan_hui 02-01-2013 14:21

Re: Philosophies on design reuse
 
My interpretation of that rule is that you can use previous concepts, but say you design a chassis that is completely perfect and use it one year. You cannot rebuild the exact same chassis (down to the same exact holes) in each part and use it the next year. One theoretical exception is if you make the chassis COTS, in which case yes, you can reuse the same exact design. Otherwise, you'd have to modify the chassis in some way (which you most likely would given the difference in the rest of the robot).

Simply put, you can reuse concepts, but not finalized designs. You can do general design before kickoff, but you still have to (read should) do some design and modification after kickoff.

Madison 02-01-2013 14:29

Re: Philosophies on design reuse
 
Any preseason work that we do only serves to inform the decisions we make during the season. There's always something we want to tweak, improve or change from what we've done in the past. I suspect that's true of most teams, but for some, the changes are small and go unnoticed by a majority of observers.

nathan_hui 02-01-2013 14:32

Re: Philosophies on design reuse
 
Now here's a question - how small a change is too small? If you did a paint job on one design and didn't do it for the other, is that a legal change?

StevenB 02-01-2013 15:13

Re: Philosophies on design reuse
 
Prior to 2007, the rules only specified that fabrication had to be done during the build season:
Quote:

Originally Posted by FRC 2006 Game Manual
... But absolutely no fabrication or assembly of any elements intended for the final robot is permitted prior to the Kick-off presentation. Any MECHANISMS assembled prior to the Kick-off presentation may be used for prototyping or educational purposes, but MAY NOT be used on the final ROBOT.

Thus, it used to be legal to take a CAD drawing of last year's robot and make another copy. As FIRST has struggled to define what it means to "build a robot", this restriction has gotten tighter. While I don't think teams are intentionally breaking the rule, older teams are more likely to have the old mindset where detailed design reuse was completely legal.

Tom Line 02-01-2013 15:40

Re: Philosophies on design reuse
 
The newest set of rules (2012) are straightforward.

Robot elements designed or created before the Kickoff presentation, including software, are not permitted.

The example even goes so far as to mention programming, and that teams should not copy over large chunks of code from year to year.

So the rules are straight forward and the intent is clear. Follow them to the best of your ability, and make your Grandmother proud.

Jon Stratis 02-01-2013 15:41

Re: Philosophies on design reuse
 
This is a bit of a tough area to come up with a hard "Rule" on - there's an entire spectrum of what many would consider "reuse", and no obvious gap that would separate acceptable from non-acceptable.

First, lets cover the obvious - If you build something before the season starts, you can't use it. Period. End of story (in 2012, at least... we need to wait a few days to make sure things haven't changed for this year!). All parts on the robot must have actually been built this season.

Now, what about the not-so-obvious? Let me give you some examples.

In 2008 we used an elevator. That elevator was held together using small plates with bearings on either side. The plate got bolted to one section of the elevator, and the bearings would then ride up and down the next section. It worked out well for us, and in 2011 we did almost exactly the same thing. I say almost, because the elevators were quite different. For the part that matters here, 2008 used 1x2 box tubing, 2011 used 1x1 box tubing. So, our plates were 1" smaller in 2011. Reuse of a design concept? Yes. Reuse of a design? No. There were differences (although the difference is minimal), and there was no CAD or specific design tolerances - we just built it and eyeballed where the holes should be each time.

How about another example... in 3 of the past 6 years we've used a 6 wheel, drop center design. Every time we used KoP wheels in the middle, with Omni wheels on the corners. They were all chained together, and chains run up to the gearbox included in the KoP for that particular year. We ended up with something that was virtually identical each year. Reuse of a design concept? Definitely. Reuse of a design? Technically, no. There was no specific design we reused. It was built with the KoP chassis and parts given to us (except for the omni wheels), which meant that things naturally turned out pretty similar. There are only so many ways to chain together a pair of wheels!

One last example. This year, you want to use CIMple boxes instead of the provided ToughBox Mini's. So, you pull them off last year's robot and stick them on. Reuse of a concept? Not really. Reuse of a design? Again, not really... However, the CIMple boxes, if I remember right, come unassembled. So, reusing them in this way is technically illegal, as they aren't in their COTS condition (you would have to disassemble them and reassemble for it to be legal). For my team, we often reuse gear boxes from one year to the next (especially BaneBots ones). While you can approach it and think "taking them apart and putting them back together to meet the technical definition of the rule sucks", it's much better to think "We should take them apart, clean them, and understand what sort of wear goes on during the season. do we need to replace any gears? What happened to the grease that was in the gearbox, and why does it look nasty now?". It turns into a learning experience where the students not only get the same experience they would if purchased new, but additional experience they wouldn't have gotten otherwise.


For me personally, I draw the line for my team by asking the question "what did you learn doing that?" If you can say the students learned something the first time it was built (off-season or previous year) that wasn't learned re-building it, then you have a problem. Many times, if we want to "reuse" a previous design, we'll look at it, figure out the good and the bad, and look for ways to improve it.

This off-season, our team built 2 arms that work in different ways on 2 vex robots we threw together (we've never built an arm before). If we decide to build a robot with an arm once the game is released, you can bet those two arms will be front and center to aid in our design, and we might end up with something that looks pretty similar to one or the other.

BigJ 02-01-2013 15:44

Re: Philosophies on design reuse
 
Quote:

Originally Posted by Tom Line (Post 1206567)
The newest set of rules (2012) are straightforward.

Robot elements designed or created before the Kickoff presentation, including software, are not permitted.

The example even goes so far as to mention programming, and that teams should not copy over large chunks of code from year to year.

So the rules are straight forward and the intent is clear. Follow them to the best of your ability, and make your Grandmother proud.

Except for the blue box mentioning...

Quote:

Originally Posted by Blue Box
Example: A different team develops a similar solution during the fall, and plans to use the
developed software on their competition Robot. After completing the software, they post
it in a generally accessible public forum and make the code available to all teams.
Because they have made their software generally available (per the definition of COTS, it
is considered COTS software and they can use it on their Robot).

I would argue that CAD designs "made public" should also count as COTS.

Rewriting code that instead could be reused (outside of educational purposes) or designed for reuse in the first place is a "bad thing" and should not be encouraged (in my opinion).

JesseK 02-01-2013 18:51

Re: Philosophies on design reuse
 
Quote:

Originally Posted by BigJ (Post 1206569)
I would argue that CAD designs "made public" should also count as COTS.

Rewriting code that instead could be reused (outside of educational purposes) or designed for reuse in the first place is a "bad thing" and should not be encouraged (in my opinion).

To what extent? (further explanation)

To be fair to Cory (that post is from 2007), every time I've looked at 254's 'bots at champs (every year since '07) there's probably very little that goes through no re-design of some sort due to new considerations.

Needless to say, there are many varied opinions.

My team uses pre-season items as prototyping platforms. Often times we'll have the entire drive train CAD'ed on the day of kickoff, just because we understand our simple drive trains that well. Then we fab the production drive train -- it's often similar to the prototype but it's never been identical. Only one part last year wound up being identical to the same part on 2011's robot, but that was after a design derivation and not a duplication. Seems to be within the spirit, even if we didn't open-source our robot.

Cory 02-01-2013 20:19

Re: Philosophies on design reuse
 
Quote:

Originally Posted by JesseK (Post 1206684)
To what extent? (further explanation)

To be fair to Cory (that post is from 2007), every time I've looked at 254's 'bots at champs (every year since '07) there's probably very little that goes through no re-design of some sort due to new considerations.

Needless to say, there are many varied opinions.

My team uses pre-season items as prototyping platforms. Often times we'll have the entire drive train CAD'ed on the day of kickoff, just because we understand our simple drive trains that well. Then we fab the production drive train -- it's often similar to the prototype but it's never been identical. Only one part last year wound up being identical to the same part on 2011's robot, but that was after a design derivation and not a duplication. Seems to be within the spirit, even if we didn't open-source our robot.

I believe we actually changed the parts in question a bit in 2008.

In all seriousness, even if you had a part that did not change at all there are endless ways you could change the design so it's not being reused. You could change the CAM file that generates the G-code to run the machine. You could make trivial dimension changes. You could issue a new drawing revision for some minor callout. You could change radii used on pockets/edges. The list goes on and on.

It's really a silly rule because FIRST is unwilling and probably more importantly unable to outline what qualifies as changing the design enough for them to be OK with it. It's also silly because anything you would re-use exactly as it was from the year before/offseason/etc is most likely a completely trivial part that would gain you no competitive advantage by designing up front.

The rule quite obviously exists to prevent you from designing an entire system of your robot before kickoff and then implementing it immediately, but you really can't design a system that can be used wholesale with no changes, because you have no idea what it needs to do.

DonRotolo 02-01-2013 20:23

Re: Philosophies on design reuse
 
Quote:

Originally Posted by ToddF (Post 1206529)
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.

Bravo, not only is the team really moving forward by learning valuable things, they have a mentor (you) who is asking for a community opinion on something that is admittedly a grey area. We need more mentors like you.

We re-use the same drivetrain concept every year, but redesign it to accommodate whatever transmissions, wheels, and manipulators needed for the game. We don't actually design it before we know what the game is, but it generally has 2 side plates forming a drive assembly (1 for each side) and a frame connecting each assembly into a chassis.

So, in your case, if you use the basic concept, but adjust the material choice, drilled holes, and other details to fit your game-specific design, you should be OK.

If you really want to use the exact design, you must not unless you publish the details (e.g., a dimensioned drawing, CAD files, etc) sufficient for other teams to duplicate it - by posting it publicly* you have made it COTS, and therefore OK to use.

It is a judgment call. Your kids will learn something from how you approach this. Make your grandmother (who knows both the rules and the intent better than all of us) proud.

*In a reasonable easy place to find it, not hidden somewhere, of course.

DampRobot 02-01-2013 21:20

Re: Philosophies on design reuse
 
To me, this is the type of ethical dilemma that is an intentional grey area. It's like deciding to have a highly sponsor fabricated robot or a team where the mentors have a more hands on approach. It's something up to the team, and FIRST isn't going to regulate it at all. (Please don't let this devolve into a Student Build vs. Mentor Built thread...)

If your team decides that it's illegal or unethical to design things before the season, that's your decision. Just know that you'll be competing against teams that do, and FIRST isn't going to do much about it.

Cory, I respect your team, and I don't mean to call you out, but your drivetrain is so similar year to year that certain interpretations of the rules would rule out your type of design reuse. My personal opinion it's in the best interests of FIRST to allow this type of reuse of design (keeps kids working, thinking, designing, learning, and inspired year round). And, like Cory mentioned, parts can easily have superficial changes to make them legal under certain rules readings. So, it's not as illegal to reuse designs as some would have us think.

Teams that design before the season, whether they actually use this design in season or not, have a advantage. They will know how to design, and they might just have a few good ideas ready to go.

jvriezen 02-01-2013 21:25

Re: Philosophies on design reuse
 
Numerous times the topic of re-using something fabricated from a previous year (we often have had a non-functional robot by the next build season and reuse COTS components) there is always a student who says something like

"Why can't we just re-use the bumper fabric with our team numbers already on them, how will 'they' know ?"

I then proceed to explain to them (or get them to realize) that 'they' are (in part) the judges and inspectors at the competition and did they notice that one of their mentors is a Lead Robot inspector and two other mentors are Inspectors?

Its hard to get the notion across that there really is no 'they' and 'us'-- we are all part of the big FRC family.

ajlapp 02-01-2013 21:39

Re: Philosophies on design reuse
 
Quote:

In all seriousness, even if you had a part that did not change at all there are endless ways you could change the design so it's not being reused. You could change the CAM file that generates the G-code to run the machine. You could make trivial dimension changes. You could issue a new drawing revision for some minor callout. You could change radii used on pockets/edges. The list goes on and on.

It's really a silly rule because FIRST is unwilling and probably more importantly unable to outline what qualifies as changing the design enough for them to be OK with it. It's also silly because anything you would re-use exactly as it was from the year before/offseason/etc is most likely a completely trivial part that would gain you no competitive advantage by designing up front.

The rule quite obviously exists to prevent you from designing an entire system of your robot before kickoff and then implementing it immediately, but you really can't design a system that can be used wholesale with no changes, because you have no idea what it needs to do.
Exactly.

R.C. 02-01-2013 21:50

Re: Philosophies on design reuse
 
Quote:

Originally Posted by ajlapp (Post 1206778)
Exactly.

You must spread some Reputation around before giving it to Cory again.

Hate when this happens...

-RC

Madison 02-01-2013 22:10

Re: Philosophies on design reuse
 
Quote:

Originally Posted by DampRobot (Post 1206769)
Cory, I respect your team, and I don't mean to call you out, but your drivetrain is so similar year to year that certain interpretations of the rules would rule out your type of design reuse.

The thing is, at this stage, I'm sure that 254 doesn't need any existing information about their drive from their old robots and could 'design' it again -- where design is taken to mean that they'll create all digital and physical assets from nothing -- in a trivial amount of time. Perhaps they already do. Does redoing the work of making part models and writing gcode constitute a new design? Do they have to arbitrarily move holes, change tolerances, or alter the shape of some component to arrive at a new design?

If you accept the latter option as the definition of a new design, which is to say that teams must make parts materially different from year to year, I don't believe that anyone outside of these teams is qualified to make a judgement about whether it's changed. So, why bother?

I don't think you can expect to regulate what it means to reuse a 'design'. The better approach, and that which I think FIRST has so far followed, is to create a competitive environment that rewards systems and strategies that are specialized to game tasks.

Tristan Lall 02-01-2013 22:26

Re: Philosophies on design reuse
 
Quote:

Originally Posted by Cory (Post 1206755)
In all seriousness, even if you had a part that did not change at all there are endless ways you could change the design so it's not being reused. You could change the CAM file that generates the G-code to run the machine. You could make trivial dimension changes. You could issue a new drawing revision for some minor callout. You could change radii used on pockets/edges. The list goes on and on.

It's really a silly rule because FIRST is unwilling and probably more importantly unable to outline what qualifies as changing the design enough for them to be OK with it. It's also silly because anything you would re-use exactly as it was from the year before/offseason/etc is most likely a completely trivial part that would gain you no competitive advantage by designing up front.

I'm entirely in agreement with Cory on this point.

Absent guidance from FIRST, there is no standard for defining a change. If you paint the part differently, is that a design change? Different colour? Different composition? Different number of coats? Different method of application leading to different surface finish? Which functional characteristics are considered and which are neglected? To what degree must a design change be intentional, and/or consequential? What if you intend to make a change (as evidenced by your latest drawings), and then don't make the change—so that the part is now identical to a pre-season revision?

If you go down this road, there is no bright line, and thus there will inherently be inconsistency in interpretation. If FIRST accepts the inconsistency and its consequences, they ought to clearly say so. But if that inconsistency is incompatible with their stated motivations (I believe that it is), then they shouldn't make rules in this fashion. (Inconsistency in the rules adds the potential for conflict, so unless it is counteracted by a significant benefit, it should be avoided.)

Quote:

Originally Posted by Cory (Post 1206755)
The rule quite obviously exists to prevent you from designing an entire system of your robot before kickoff and then implementing it immediately, but you really can't design a system that can be used wholesale with no changes, because you have no idea what it needs to do.

As I see it, FIRST should reconsider its intent: allow teams to design (and prototype) whatever they want before the build season, even if the design is destined for the final robot. That way there are no issues regarding what individual custom components remained the same through the pre-season and in-season design processes, despite being part of assemblies that were reconfigured during the season.

What's the worst that could happen? Teams could design robots and mechanisms in the hopes of having a suitable game? They could do engineering stuff year-round? Fine with me, and obviously fine with a lot of the more dedicated and more successful teams. Presumably fine with FIRST, too, since they haven't really done anything effective to curb it.


Additionally, the previous years' rules were hopeless from an enforcement standpoint because (in the general case) it is not practical for an official to evaluate all of the possible elements that could have been changed on moderately complex systems. Indeed, in nearly every case, the officials have no access to the previous designs (whether in schematic or constructed form) at all. The proposal I outlined above doesn't remedy this entirely, but simplifies the task considerably, because it then comes down to a simple question that can be much more clearly understood and answered by the team: "did you fabricate or modify any robot parts before the build season began?" (Granted, that is dependent on a good definition of fabrication/modification, but that's already covered for the most part in the rules.) Instead of the inspector having to evaluate the robot based on the dates of design changes, they evaluate it based on dates of modification. Modification is much more of a momentous event than design revision, and since it is more likely that any given team member will be aware of it, it's harder for them to forget or lie about at inspection. (And perhaps more importantly, if the team member does forget/lie, they're more likely to be called out on it by a fellow team member later on—so violators lose the shield of plausible deniability among the people whose approval they value most.)

Besides, my position is that (in a typical FRC game, rather than universally) an inspector should be giving the teams the benefit of any plausible interpretation within the rules. The teams are not the source of unclear rules, and they should not be penalized for successfully following a reasonable interpretation of those rules. (As a result, inter-event inconsistency sometimes ensues, but it is typically balanced by the fact that the teams are able to play, unburdened by surprise modifications, having complied with the apparent letter of the rules.)

dtengineering 02-01-2013 23:15

Re: Philosophies on design reuse
 
We learn things as we go along in FRC. What we learn enables us to design better machines faster. It sounds like you learned a lot in the off-season. Never be afraid to embrace what you have learned, and use that knowledge on your machine.

I guess my suggestion, however, would be that the off-season and previous season knowledge should be stored in a human, or group of humans, rather than in a data file. After all, FIRST isn't really about the robot.

So in the event that the game that is announced on Saturday is perfectly suited for your off-season design, then just sit down at your computer, start with a blank CAD file, and re-create your design from scratch.

It might be identical to the off-season design, but you will have done the work during build season... you'll simply have done it faster, with more confidence and less troubleshooting because of experience you gained in the off season. By demonstrating your knowledge of a good design you'll not only be within the letter of the rule, but also the spirit of the rule.

Most likely, however, you'll find yourself making a few tweaks here and there to improve the off-season design or customize it for the game... I mean, what are the odds you'd build something so perfectly that it couldn't be improved upon a little bit?

Jason

Wildcats1378 03-01-2013 01:22

Re: Philosophies on design reuse
 
I've never quite understood how FRC enforces this rule in the first place. Programming, for example: how does FRC know when you've copied code from last year?

Has anyone actually been disqualified for this? It seems more like a moral guideline then an actual rule.

DampRobot 03-01-2013 01:35

Re: Philosophies on design reuse
 
That is exactly what it is. A moral guideline rather than a rule (such as robot weight, number of appendages, etc).

Cory 03-01-2013 02:33

Re: Philosophies on design reuse
 
Quote:

Originally Posted by DampRobot (Post 1206769)
Cory, I respect your team, and I don't mean to call you out, but your drivetrain is so similar year to year that certain interpretations of the rules would rule out your type of design reuse.

If you actually sat down and compared CAD models there are subtle differences between every drivebase. There is only one part I can think of that is not materially different year to year and even then things change slightly in the manufacturing process and material selection, which is easily considered part of the design of the part. Every single other part that looks the same has experienced a meaningful design change every year it has been used, for at least the last 4-5 years.

IKE 03-01-2013 08:23

Re: Philosophies on design reuse
 
Quote:

Originally Posted by ToddF (Post 1206529)
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. ....

ToddF,
I concur with others on congratulations on doing some off-season work to make your team better.
While the rule seems pretty clear cut, some of the blue box examples make it otherwise.
Also keep in mind that FIRST sponsors BETA Test teams to test the software. Some things they learn will get rolled out to other teams, but not every detail.

I think the strong feelings that differ on this topic may stem from a difference between Academia and Corporate world. In academia, if you use someone else’s thoughts to explain a position without referencing it, then you are plagiarizing. This position puts an interesting emphasis on original work.
Often on engineering projects, you are requested to use "Lessons Learned", re-use internal designs that have been validated, or attempt "Commonality".

When these two cultures read the same rule, they have slightly different interpretations. I would almost guarantee you that at certain regionals, if you did a big sales pitch in the pits about "commonality", "design libraries", and using TDS (Toyota Development System) principles of reusing reliable designs you could likely win a Quality of Industrial Design award. Winning awards doesn't make it right, but it does speak to the disconnect of some views on this subject, and what industry professionals (often the biggest chunk of Judges) would love for students to be able to bring to the table.

One of my favorite students to go through our program was obsessed with originality his first two years. He designed some really neat but fairly impractical designs. We talked to him about benchmarking and paying attention to good design details. Having Form follow Useful Function (most of his early designs were more about unique Form to create novel function). The stuff he churns out now is really impressive. On the surface it may look like something you have seen before, but the details are really impressive.

Per "apalard's" post about re-using, to my knowledge, the closest we came to re-using a major system was the chassis project of 2010 and our competition chassis of 2011. They were really close but arguably different in many, many, many aspects. That being said, our 2006, 2007, 2008 chassis were all 6x6 sheet metal designs with dead axles and shiftable transmissions. The architectures were similar (especial 2007 and 2008) but all the design details were different.

Ultimately, your team will have to figure out where their comfort is.

Oh, and I would recommend not doing a swerve drive for the first time during the build season. FYSS (First Year Swerve Syndrome) is a well documented condition that has the symptoms of early delusions of grandeur followed by countless headaches, sleeplessness, depression, irritability, and in some cases I have seen it be fatal (to a team).

tim-tim 03-01-2013 08:49

Re: Philosophies on design reuse
 
You should always be able to make the design better.

We view the off-season as a research and development period. We gain a lot in the proof of concept categories. Almost none of our work would be competiton worthy, for reasons such as material selection, manufacturing techniques, weight, etc.

Look at your concepts/designs and improve them. You and your team probably learned a lot from the experience of the off-season; now put those lessons learned to work.

Tom Line 03-01-2013 09:13

Re: Philosophies on design reuse
 
Quote:

Originally Posted by Wildcats1378 (Post 1206842)
I've never quite understood how FRC enforces this rule in the first place. Programming, for example: how does FRC know when you've copied code from last year?

Has anyone actually been disqualified for this? It seems more like a moral guideline then an actual rule.

FRC can't enforce the rule. Of course, that begs the question "Why should they need to?"

If teams are really trying to stick by the rules as closely as possible, they already realize that reuse of entire designs or entire chunks of code is a no-no. Unless they post them on-line and make them available to everyone. I believe that's the end goal: to have teams sharing information freely (after the season and before the season) in order to bring everyone along.

If teams didn't share freely, you wouldn't see products like AndyMark's super shifter (designed in 2004 for team use), their AM planetary, and other products / designs. See the trapezoidal motion profile thread for a great example of teams who have a competitive advantage helping to bring others up to speed.

Of course, this all assume that teams get the idea of Gracious Professionalism. I'm going to continue to assume that. Most of the big-name teams constantly prove it (kit-bot on steriods, etc).

IKE 03-01-2013 09:57

Re: Philosophies on design reuse
 
Quote:

Originally Posted by Wildcats1378 (Post 1206842)
I've never quite understood how FRC enforces this rule in the first place. Programming, for example: how does FRC know when you've copied code from last year?

Has anyone actually been disqualified for this? It seems more like a moral guideline then an actual rule.

The only time I have seen a clear ability to enforce the rule was when a custom piece had an inspection sticker from a previous year on it. I also saw a team bring last years robot to a competition (I think it was 2011, and they brought a 2010 bot). I believe they packed up and left (if memory serves me right).

philso 03-01-2013 13:35

Re: Philosophies on design reuse
 
If a team is using the AndyMark C-channels, and they happen to determine that they should use the same motors, gearboxes and gear ratios and the same size wheels, as they had used in a previous year, they will end up with the "same design" for their drive base. It will also likely be pretty much the same as the drive base used by a number of other teams who arrived at the same solution. I don't feel this is bad as long as the teams went through the engineering exercise that happened to lead them to a solution they had used before since this is an engineering competition and one of it's goals is to teach the team members how do work through the engineering exercise. As someone had posted in an earlier reply "FIRST isn't really about the robot".

Wayne TenBrink 03-01-2013 13:41

Re: Philosophies on design reuse
 
I would go one step further and argue that some amount of unregulated (predesigned and/or prefabricated) components/mechanisms should be allowed. Perhaps 10 or 20 lb (analagous to the withholding allowance) and only on the condition that you share the design and declare the items on the BOM.

Teams would still need to build a new robot every year, but at least they would benefit from the same advantages you get with buying a COTS mechanism. With all the FRC-specific COTS items on the market today, why invest time and money into building something that you can only use once, when you can buy a comparable unit and re-use it? Examples include gearboxes, swerve mechanisms, and now even entire drive modules.

In many cases, using a pre-designed or pre-fabricated mechanism would be more of a detriment than a benefit, because it would involve compromising function for convenience.

The current rules made more sense when every team had to make every mechanism because nobody could buy them. That isn't so true any more, and the FRC-COTS market is likely to grow. This might reduce the artificial exercise of lawyering our way around rules that are not and cannot be uniformly enforced in the first place.

AdamHeard 03-01-2013 14:43

Re: Philosophies on design reuse
 
Raul posted a similar idea years ago, and I really like it.

Allowing 20 lbs of custom items to be reused year to year won't make good teams any better, but it will really help the rest of the teams substantially.

Quote:

Originally Posted by Wayne TenBrink (Post 1206951)
I would go one step further and argue that some amount of unregulated (predesigned and/or prefabricated) components/mechanisms should be allowed. Perhaps 10 or 20 lb (analagous to the withholding allowance) and only on the condition that you share the design and declare the items on the BOM.

Teams would still need to build a new robot every year, but at least they would benefit from the same advantages you get with buying a COTS mechanism. With all the FRC-specific COTS items on the market today, why invest time and money into building something that you can only use once, when you can buy a comparable unit and re-use it? Examples include gearboxes, swerve mechanisms, and now even entire drive modules.

In many cases, using a pre-designed or pre-fabricated mechanism would be more of a detriment than a benefit, because it would involve compromising function for convenience.

The current rules made more sense when every team had to make every mechanism because nobody could buy them. That isn't so true any more, and the FRC-COTS market is likely to grow. This might reduce the artificial exercise of lawyering our way around rules that are not and cannot be uniformly enforced in the first place.


wilhitern1 03-01-2013 16:06

Re: Philosophies on design reuse
 
Quote:

Originally Posted by AdamHeard (Post 1206969)
Raul posted a similar idea years ago, and I really like it.

Allowing 20 lbs of custom items to be reused year to year won't make good teams any better, but it will really help the rest of the teams substantially.

If I remember the rules correctly... (probably not)... If you fully publish everything about how to build your design. You can then use 100% of it year over year...

Neal

I'll have to go back and check the manual on that.

Nemo 03-01-2013 17:01

Re: Philosophies on design reuse
 
Quote:

Originally Posted by wilhitern1 (Post 1206994)
If I remember the rules correctly... (probably not)... If you fully publish everything about how to build your design. You can then use 100% of it year over year...

Neal

I'll have to go back and check the manual on that.

I believe Adam is talking about the idea of reusing a certain amount of physical parts from a previous year. It's an interesting idea since at first glance it seems to go against the nature of the competition as it currently exists. I think I like the idea since it would help the finance situation for some teams. I don't really see a world class team creating, for example, a set of awesomely light / compact / machining intensive swerve modules and reusing them every year. Instead they'd probably choose to make subtle improvements and fabricate the new version each season. But I could see a team benefiting from the ability to reuse a C-Channel with a couple of holes drilled in it.

The idea of publishing your design to legally use it in competition only appears in the manual regarding software (2009-2012 rules). The manual doesn't really provide an answer as to whether publishing CAD drawings makes it legal to reuse a design. But as others have said, it's basically a moot point since you can make a trivial modification and then be technically legal.

It should simply be legal to design stuff before the build season.

robert.hatchett 03-01-2013 19:50

Re: Philosophies on design reuse
 
I have read the entire thread and appreciate the nuances presented. However, I feel I need to comment.

I would ask all who have offerred opinions to recall we are MENTORS and as such have the RESPONSIBILITY to teach, not only engineering principles, but engineering ethics in the spirit of the engineering canon and also the spirit, if not the letter, oft FIRST principles and rules.

Repackaging of items prior to kickoff should pass the oft-quoted "make your grandma proud".

dtengineering 03-01-2013 22:24

Re: Philosophies on design reuse
 
Quote:

Originally Posted by AdamHeard (Post 1206969)
Raul posted a similar idea years ago, and I really like it.

Allowing 20 lbs of custom items to be reused year to year won't make good teams any better, but it will really help the rest of the teams substantially.

In general I'm pretty good with the idea that everything is designed, built and programmed during build season... the designing, building and programming is done based on what you learned in the off season, and might be really similar to something that you've built before, but I like the simplicity of the rule.

Where it did bother me, though, was in the needless waste of certain items, most noticably bumpers. We'd do it... we'd slice up new plywood, purchase new pool noodles, buy new fabric and label it (or not) as required. It wasn't a big waste when we only needed one set of bumpers every year, but it did seem a bit needless to build two sets every year when they could have been cut down or modified.

So from a game persepective, I'm good with the rules as they are, but from a cost and waste persepective, a modification of this type makes sense.

Jason

wilhitern1 04-01-2013 07:26

Re: Philosophies on design reuse
 
Quote:

Originally Posted by robert.hatchett (Post 1207058)
Repackaging of items prior to kickoff should pass the oft-quoted "make your grandma proud".

I've never had that problem, since my kids always want to try something extreme!

Tom Line 04-01-2013 07:57

Re: Philosophies on design reuse
 
Quote:

Originally Posted by dtengineering (Post 1207119)
In general I'm pretty good with the idea that everything is designed, built and programmed during build season... the designing, building and programming is done based on what you learned in the off season, and might be really similar to something that you've built before, but I like the simplicity of the rule.

Where it did bother me, though, was in the needless waste of certain items, most noticably bumpers. We'd do it... we'd slice up new plywood, purchase new pool noodles, buy new fabric and label it (or not) as required. It wasn't a big waste when we only needed one set of bumpers every year, but it did seem a bit needless to build two sets every year when they could have been cut down or modified.

So from a game persepective, I'm good with the rules as they are, but from a cost and waste persepective, a modification of this type makes sense.

Jason

Jason, I never even considered this until you mentioned it.

Reusing bumpers provides absolutely no competitive advantage to teams. In addition, being able to make one set and reuse it might result in much nicer bumpers - I know we'd probably put more work into them if we could reuse them multiple years.

Dear FIRST - ALLOW bumper reuse!!!!

s1900ahon 04-01-2013 14:29

Re: Philosophies on design reuse
 
Quote:

Originally Posted by BigJ (Post 1206569)
I would argue that CAD designs "made public" should also count as COTS.

I agree with your assertion in principle simply because it is consistent, but let's be honest, posting software for others to use is much more beneficial to others than posting a mechanical CAD design.

The software may be used by almost anyone; even if it is posted for a language/environment your team does not use. Algorithms and data structures can be translated. Moreover, even if the software runs on a platform other than the cRIO, the platform is very likely available to you (*).

The benefit to other teams if you post your CAD files is predicated on the other teams having access to the same manufacturing facilities as yours. A design of a custom chassis that requires access to a laser cutter, a turret punch, and a CNC brake does not help most other teams. In fact, I'd go as far as to say that posting the CAD design largely benefits the team posting the design since they'd be able to re-use it and others with similar capabilities would do their own thing.

-Scott

(*) If the software runs on a device that is a custom circuit, the rules
that the custom circuit must be fabricated during the build season (assuming the Gerbers, schematics, and other files were posted to make them COTS too). The lead times for affordable PCB manufacture and assembly make this difficult, and that practicality leads implementation towards COTS computing platforms such as the Raspberry PI, BeagleBone, Arduino, etc.

BigJ 04-01-2013 14:49

Re: Philosophies on design reuse
 
Quote:

Originally Posted by s1900ahon (Post 1207294)
I agree with your assertion in principle simply because it is consistent, but let's be honest, posting software for others to use is much more beneficial to others than posting a mechanical CAD design.

The software may be used by almost anyone; even if it is posted for a language/environment your team does not use. Algorithms and data structures can be translated. Moreover, even if the software runs on a platform other than the cRIO, the platform is very likely available to you (*).

The benefit to other teams if you post your CAD files is predicated on the other teams having access to the same manufacturing facilities as yours. A design of a custom chassis that requires access to a laser cutter, a turret punch, and a CNC brake does not help most other teams. In fact, I'd go as far as to say that posting the CAD design largely benefits the team posting the design since they'd be able to re-use it and others with similar capabilities would do their own thing.

-Scott

(*) If the software runs on a device that is a custom circuit, the rules
that the custom circuit must be fabricated during the build season (assuming the Gerbers, schematics, and other files were posted to make them COTS too). The lead times for affordable PCB manufacture and assembly make this difficult, and that practicality leads implementation towards COTS computing platforms such as the Raspberry PI, BeagleBone, Arduino, etc.

I agree. But in accordance with your statement, having, say, 254's codebase doesn't really help me directly unless I configure a system exactly like theirs with the same sensors, etc. However, it does give me something entertaining to look at and which to draw ideas from for the next season, much like openly distributed CAD designs :)

I will concede that replicating a sensor setup is a bit easier than replciating an entire machine shop for any team that wished to go the carbon copy route, although I don't know why any team would. :)

s1900ahon 04-01-2013 17:35

Re: Philosophies on design reuse
 
Quote:

Originally Posted by BigJ (Post 1207308)
I agree...<snip>... However, it does give me something entertaining to look at and which to draw ideas from for the next season, much like openly distributed CAD designs :)

Agreed. I learn quite a bit each year from the mechanical pics, posts, and designs shared by others (my degree is in EE with a minor in CS).

And while I "ooh" and "ah" as I look through the latest 148 design each year, I know that the sharing of their SolidWorks files won't affect my team as directly as someone who posts software.

But, this is the nature of the beast. That being said, I believe that sharing a design file, regardless of the contents, should allow the contents to be considered COTS. It is just consistent and simple, despite my view of the difference in global utility.


All times are GMT -5. The time now is 00:17.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi