What's with all of the code and CAD releases over the last couple of weeks?

You might have noticed the sudden burst of teams posting links to their prior year’s code and CAD drawings on Chief Delphi. Wondering why? Read on.

R15 of the 2018 Game and Season Manual says:

Software and mechanical/electrical designs created before Kickoff are only permitted if the source
files (complete information sufficient to produce the design) are available publicly prior to Kickoff.

While we don’t know what the rules are for 2019, that section has been present for many years. Odds are you’ll see a similar section again next Saturday.

So, if you have that regional-winning robot vision library, or that crazy 5 CIM continuously variable gearbox from last year’s bot, and want to use it on this year’s robot, you need to publish the design.

What does *publish *mean? The examples in the rules all say:

  • post it in a generally accessible public forum
  • make the code available to all Teams

A story. A couple years ago at a competition I was asked to consult on a robot’s control system issue. We spent quite a bit of time going through the source code of the robot to see what the issue was. Reading the source code, it was clear to me that the code represented many years worth of work.

After the competition, I took a look around for the team’s code, and wasn’t able to find it online anywhere. That’s not right.

The concept behind R15 is that the work product – the robot and its code – represents the work of the current team. Sharing of designs and source code helps level the playing field and increases the quality of robots from all teams. It deliberately reduces the (big) advantage that veteran teams have over new ones.

Finally, a personal note. I love reading team’s robot code, and would love to see more published code to look at.

So, there you go. Publishing your code and designs = good.

3 Likes

What is the best format for doing this? I noticed teams were creating individual threads for their work, but I think with everyone trying to get things uploaded at the same time it all gets kind of lost. Is it better to do that, or say reply to this thread instead so that everything is together?

1 Like

R15 exsists. Never heard of anyone who enforces it.

For code it’s pretty straight forward.

However, It’s also kind of vague in what constitutes publishing designs. You have teams that post entire CAD models, others that post pictures of CAD models, other just post pictures of the assembled components. I would like to see the rule on the physical design made more specific.

I feel like a thread were all teams could post would be nice separate ones for cad and code

Good suggestion. Next year I’ll change the title to reflect this.

At the same time, separate threads for each team’s releases allow the discussion to stay much more sane. Some teams’ releases (say, 148) attract a lot more attention than others (say, 1293’s).

I have a hard time believing a screenshot of a CAD drawing is “complete information sufficient to produce the design”.

Yay for ex post facto rules!

3 Likes

I think making one’s own thread is better. It allows discussion to stay focused on the particular item in question.

The rule doesn’t require a one-stop-shop for all FRC open source designs or anything, it just requires public accessibility if people want to seek it out or find it. A separate thread is most appropriate for this.

Depends on the screenshot. If it contains relevant dimensions then it should consititute enough info to produce the design. The rule has never said anything about the level of effort required to recreate the design.

I agree with what you say, but what you describe strikes me as “a drawing” not “a screenshot”.

Wouldn’t a screenshot of a (full) drawing be the same thing as a drawing? As long as it’s a complete part definition.

Would screenshots of code be sufficient as well?

Potato, Potahtoh?

A series of pixels arranged in a pattern that is commonly accepted to display certain information :stuck_out_tongue:

R14 is one of those “follow the intent” rules imho. The intent is “you should publish your crap if you wanna use it”

In a shocker to nobody, I agree with @marshall that R14 should move into the evergreen rules so as to not have rules that we had to follow prior to having the rules. Either that or add a buffer zone for “must be released prior to Kickoff + 1 week” to enable us to realize “oh yeah, we have this thing we designed up last year and never went far with, we should pick that back up”.

I understand the intent of release everything but in a lot of cases it leads to a lot of chaff and very little wheat. This might encourage more wheat to be published.

“But the plans were on display…”
“On display? I eventually had to go down to the cellar to find them.”
“That’s the display department.”
“With a flashlight.”
“Ah, well, the lights had probably gone.”
“So had the stairs.”
“But look, you found the notice, didn’t you?”
“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”

Beware of the leopard indeed.

4 Likes

Is it generally considered necessary to publish a note to a public forum like CD, or enough that your code is in a public repository like on GitHub? Whereas example #4 in R15 implies both, the rule wording itself is fairly simply stated, and making public in GitHub seems to meet the intent. I personally don’t look for these posts by other teams on CD - I just go to their GitHub repositories. (Also, same question could be asked about CAD and OnShape.)

Well, in the past other people have tried Interpretive Jazz:

Or via Dramatic Reading:

If those count, screenshots sure ought to.

(Of course, nobody that I’m aware of (via LRI or Q&A) has made a definitive ruling on whether those count for anything, and 2019 rules may be completely different.)

1 Like