Why the sudden burst of code postings?

[MrRoboSteve]

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

R13 of the 2016 Rules (http://www.firstinspires.org/sites/default/files/uploads/resource_library/frc/game-and-season-info/archive/2015/GameManual20150407.pdf) states:

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 2017, that section has been present for many years and I would not$@#bet against$@#a similar section being present again for 2017.

So, if you have that great robot vision program from previous years, 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. Two 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. I took a note of the team's number because I was interested in reviewing the code later at home.

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 R13 is that the work product -- the robot and its code -- represents the work of the current team. Requiring 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.

[notmattlythgoe]

With that said, here (https://github.com/TripleHelixProgramming/theta_2016) is 2363's 2016 code.

[GeeTwo]

Likewise, 3946's code back to our rookie year (https://github.com/frc3946/).

[gerthworm]

I love reading team's robot code, and would love to see more published code to look at.

I agree wholeheartedly. There are many many times I've looked at a veteran team's code (Thanks 254 and 2481!) and leveraged the ideas (hopefully making them better along the way). Our team has been made much better off building from examples of more experienced teams!!!

Edit: Well, I'll join in too: https://github.com/RobotCasserole1736

[bobbysq]

https://github.com/frc4646

Check here for everything. It'll have all of our code as soon as we start it, finished or not.

[vScourge]

A great, filterable directory of released robot code:

FIRSTWiki Robot Code Directory (https://firstwiki.github.io/wiki/robot-code-directory)

[Bkeeneykid]

I've always found making a standalone post kinda tacky personally. It's not warranting of taking up more space. There are places for this: your TBA profile, your FIRSTwiki page, et cetera. But since we're all piling on here, here ya go:
https://github.com/SMNWrobotics

Notable things include our semi-beta scouting app in the FRC2016 repo, made in Xojo and what we used with four other teams last year at GKC. Never found it polished enough to show it off, but in case you are interested.

EDIT: Sniped on FIRSTwiki. Please, take ten minutes and add your team's info there if you can. It really helps us out a ton!

[tr6scott]

Well, we were going to clean this up for public release, but I guess were too lazy for that...

Of some interest maybe onboard vision processing, in labview. There are some of out bot log files for our matches, which don't do much not knowing the bot, but the code is there to do the recording if interested.

Also there are a wealth of information in the commits, but seeing I just uploaded this from our private stash, you maybe missing gems, like "my hands are typing words."

Anyways, it's out there, and posted in a public forum. :)

https://github.com/TORC2137

[frcguy]

I guess I'll get in on this.

Our Github can be found here: https://github.com/bread5940. All our code is in there - for both our robots and random projects. Several things may be of interest. FRC-2016-BREAD-Codebase (https://github.com/BREAD5940/FRC-2016-BREAD-Codebase) is all the code for our competition bot last season. It includes some cool stuff like modular autonomous, a full set of systems tests that are run before each match, a camera implementation that overlays the stream with lines for targeting, and other fun stuff. There's a full set of Javadocs generated for it, and you can find the link to those in the readme. Some other notable things: 2017beta (https://github.com/BREAD5940/2017Beta) is some code we wrote that features some of the new changes for the upcoming season, including the new camera server and imports for the new Talon SRX plugins. There's some random vision processing stuff on there as well, mainly experimentation from the off season. If anyone has any questions feel free to PM me and I'll pass them along to the appropriate people on the team.

Thanks!

[Hitchhiker 42]

Robot Code 2016 (https://github.com/FullMetalFalcons/Robot-Code-2016) is our robot code for this previous year. Also, what Devin said.

[mikhalev]

Team Tators has some code/CAD to post also.

Our CAD postings are up here (https://github.com/Team2122/TatorCAD). The only thing we have up there currently is a roboRIO mount and port protector.

Our offseason robot code is up here (https://github.com/Team2122/RoTator). This is the first time we as a team have used Java for a robot, actually. Some interesting things about what we did:

We used gradle + a custom script called build.sh to build and deploy code to the robot. Since we used gradle, we could also use external libraries easily, even between team members computers.
We split up the robot code into 4 parts.:
Desktop, which does not depend on WPILib at all and opens a GUI simulation of the robot.
Rio, which actually runs on the roboRio and contains all of the WPILib-specific code.
Core, which contains all code common to both rio and desktop.
And config, which contains YAML files which can be modified to easily change the behavior of the robot.
We have code for interfacing with an ADXRS453 gyro here (https://github.com/Team2122/RoTator/blob/master/rio/src/main/java/org/teamtators/rotator/components/ADXRS453.java). This differs from WPILib's implementation in that it measures the delay of each run of the Notifier, providing for more accurate rate integration.
We have our auton modes written in our config files (https://github.com/Team2122/RoTator/blob/master/config/commands.yml#L258), which allows for quick and easy tweaks without having to reupload code.


We are also releasing our vision code for the same robot here (https://github.com/Team2122/TatorVision). This is mostly written in Kotlin, and uses OpenCV and NetworkTables to process images from a Raspberry Pi Camera and send angle values back to the roboRIO for targetting.

That's basically it.

[Jared Russell]

We have code for interfacing with an ADXRS453 gyro here (https://github.com/Team2122/RoTator/blob/master/rio/src/main/java/org/teamtators/rotator/components/ADXRS453.java). This differs from WPILib's implementation in that it measures the delay of each run of the Notifier, providing for more accurate rate integration.


This caught my eye because we also wrote our own ADXRS453 class last season. Ours was almost entirely a copy of the wpilib ADXRS450 driver, with a couple minor tweaks: https://github.com/Team254/FRC-2016-Public/blob/master/src/com/team254/lib/util/ADXRS453_Gyro.java

Note that your implementation for the ADXRS453 does rate integration in software at 120Hz based on a Notifier callback. The wpilib implementation does rate integration in an FPGA accumulator at 1KHz.

Your method is certainly adequate for FRC use (and it's all we could do before the cRIO era), but it isn't correct to say that it is more accurate than wpilib's implementation.

[virtuald]

+1

[Thad House]

This caught my eye because we also wrote our own ADXRS453 class last season. Ours was almost entirely a copy of the wpilib ADXRS450 driver, with a couple minor tweaks: https://github.com/Team254/FRC-2016-Public/blob/master/src/com/team254/lib/util/ADXRS453_Gyro.java

Note that your implementation for the ADXRS453 does rate integration in software at 120Hz based on a Notifier callback. The wpilib implementation does rate integration in an FPGA accumulator at 1KHz.

Your method is certainly adequate for FRC use (and it's all we could do before the cRIO era), but it isn't correct to say that it is more accurate than wpilib's implementation.

For the ADXRS453, its actually not a FPGA accumulator. Its a HAL level notifier running at 200Hz. It was originally at the Java level, but that took about 50% of the CPU if I recall correctly, so it ended up being built at the HAL level.

However I will agree that the wpilib implementation is still probably more accurate. When a notifier comes from the FPGA, it actually pings a Java thread, which then enters Java. So there where always be a context switch whenever entering the Java code. This was another reason the code was done at the HAL level in WPILib. (Note there are some issues with both SPI and Notifiers not being RT threads, that will probably be fixed for 2018, as it was discovered too late and determined to not be critical enough to fix for 2017. However we have some graphs that show that the timers hit pretty much at 5ms every single time with very few misses.)

[Jared Russell]

For the ADXRS453, its actually not a FPGA accumulator. Its a HAL level notifier running at 200Hz. It was originally at the Java level, but that took about 50% of the CPU if I recall correctly, so it ended up being built at the HAL level.

Bleh, now that you mention it I remember that it is a HAL accumulator, but the 200Hz bit is news to me; all Java code and documentation suggests that the period requested by spiInitAccumulator will be honored. Stuff like that ought to be documented.