Please open source your code!

[basicxman]

We saw a lot of interesting robots this year and of course CMP will bring some interesting improvements to these already great robots. We've seen things from multi tube autonomous modes to camera tracking - it's been an exciting year for programmers.

We've found a lack of teams open sourcing their code. The FIRST community involves a lot of sharing, but so few teams are sharing code.

If you have some interesting code, especially the power house teams who are doing some extremely neat things with the help of professional software engineers - please open source!

We'd be happy to host code for other teams if you do not already have it up on a site like GitHub or Google Code.

[Chris_Elston]

Team THRUST 1501 has posted code to all our robots since 2005.

You can find our source code here. www.frcsoft.com

Enjoy...

[WEHickok]

The HOT Team makes their source code available on our website after the season is over. The code from last year is on the site right now.
http://frcteam67.dyndns.org/Programming.htm

The HOT Team allows the students to develop our code. We divide the programming group into two groups--one develops in LabView and the other in C++. The mentors guide them but do not develop code. We find that this method provides a healthy competition between the groups to be the best.

During the season we use one group's code at two events and the other at the other two events. So we used LabView at the Michigan State Championship and we will be using C++ at the Championship.

By the way, you will also find some of the drawings of our robots on our website.

After the Championship, we open everything and put it on the website in the hope that this will help make FIRST even better.

[apalrd]

Last year I posted my code here.

I am planning on posting my code after Championships.

For the past two years, all of our code has been written by me (current Junior at NDP).

This years code has a lot of goodies - beescript 1.0 (autonomous scripting), multi-tube autonomous (basically just base functions that drive and turn reliably, and a script to set the sequence/distances), elevator state-machine capable of state lookup and special state handling (e.g. score sequencing, over-the-back anti-death, and a few other special moves), and drivetrain speed control with position holding.

OH - I almost forgot - I have code to talk to a FRC-CMUcam2 from the cRio, although it isn't used due to lack of need during teleop and the time it takes to align automatically.

[GGCO]

I'd also like to see more open source code in FIRST, but you got to remember that there's already so much code given to us that I don't think every team needs to go open source.

Maybe only the teams with the most complex drive trains or best auton, but certainly not every team who just has drive forward for x, turn, etc.

[BigJ]

I'll throw out a link to our bitbucket -- it isn't kept updated very well as we can't access it from our build site. The commit history isn't very nice either because we started using it near the start of competition season. I'll be sure to update it after Championships.

Our documentation is horrible... need to work on that with the kids.

https://bitbucket.org/team1675/team1675-2011

[demosthenes2k8]

Team 166 hosts all our code on Googlecode, so it's constantly available at http://code.chopshop166.com - It contains code for our main robot (chopshop11) as well as a bunch of random code in paradebot10 - we never changed the name of it - to run different things on our demonstration robot - drive and grill.
The main body, though is the competition code, which runs on top of our Framework that we've developed over the last two years. The entire system runs in parallel, and has a special class set up to read data from each task as well as from the "physical" joysticks, which allows us to override joysticks with ease, simply by simulating them like so:

proxy->set("joy1bt", true); // This sets the trigger (JOYstick 1, Button Trigger) to true

We've also been working on improving our logging system to make it as simple to use as possible, as well as some other neat things, like automatic newpress checking and TWO different ways to create a Task with more safety and useability than the default VxWorks tasks. (One of which plays very nicely with C++0x's Lambda functions...or it would if we could use them...)

[byteit101]

451 has ours at https://bitbucket.org/byteit101/logo/src
We have our very good line following code in LineFollowing.cpp with the control in Main.cpp. The strait line code worked 11 of 12 matches at Knoxville (the 1 was my fault, I made it go faster instead of slower), and with tweaking of the height, it works with forking also.
We also have one really nice CAN loop, the minibot deployer motor has two limit switches set up near the end of Main.cpp, and we had a pot control before we removed it due to many issues with the mech (in Forklift.cpp at revision dca663151f5d )

[MaxMax161]

This gave me an idea. What if a few teams got together and over the course of 6 weeks developed a very similar code in parallel all the time publishing it to the web. Open source development. I don't think I personally would want to do this because of the time requirement getting the code out there, commenting it, ect but it's an idea.

[demosthenes2k8]

(I forgot to mention that 166's code is only C++, but we DO use a little bit of python to parse the memory logs)

Max, are you suggesting creating (basically) the same code but for all four languages? As awesome as that sounds, there are a couple of problems with it, namely, different languages might make it easier to do some things than others. For example, I haven't seen any way to create multiple "tasks" in Labview like you can in C++, but the way the language itself is set up you might not even need them - just stick the code in parallel lines and it'll execute round-robin style multitasking. (I'm not an expert in Labview, so I may be wrong)
This just boils down to "what would this open source code do that would be better than the default code for that language?" Remember, we wouldn't be able to write too much code the same unless the robots were the same.

That said, if there are some actual guidelines written up by the teams participating, and the goals clearly stated, then it MAY work.

[apalrd]

Originally Posted by demosthenes2k8

For example, I haven't seen any way to create multiple "tasks" in Labview like you can in C++, but the way the language itself is set up you might not even need them - just stick the code in parallel lines and it'll execute round-robin style multitasking.

Dragging down another While loop is a LabVIEW task.
You can also use Timed Loops which are RT tasks (they will always be called exactly at the interval you specify)
You can also use a Static Ref + Call By Ref Node to call a function by ref, and you can set one of the properties of Call By Ref to not wait before continuing (calling the ref in a new thread)

[kgzak]

We have a really nice autonomous that we will probably be using again next year (doesn't matter the game it will work) so we have to post it somewhere. I'll talk to our other programer and see if he wants to post all our code somewhere. We've been working on a Library of our own VIs that will eventually get posted on our Website.

[Robby Unruh]

Originally Posted by kgzak

We have a really nice autonomous that we will probably be using again next year (doesn't matter the game it will work) so we have to post it somewhere. I'll talk to our other programer and see if he wants to post all our code somewhere. We've been working on a Library of our own VIs that will eventually get posted on our Website.

How strict is this open source rule? Would you get penalized for essentially writing a previous years code? (ie; same task, written differently)
And how would a team that uses the default code every year end up?

All that being said, 3266's code is extremely messy, but I'll release it how we used it at Buckeye. Maybe I'll put up a cleaner version along side it, just so you guys won't associate me as the kid who writes nested ifs EVERYWHERE!

[virtuald]

We open source our code every year. It's a bit amusing to see the evolution from year to year, honestly.

This year our code was written in python. http://www.virtualroadside.com/FRC

[imac256]

Originally Posted by Robby Unruh

How strict is this open source rule? Would you get penalized for essentially writing a previous years code? (ie; same task, written differently)
And how would a team that uses the default code every year end up?

In my interpretation of the rule, as long as the code you are using is available for other FRC teams to use the rule is satisfied. Therefore open-sourcing a library which you developed this year would allow you to use it in future years (at least that is how my team has understood the rules).

My team has placed all of our code and documentation into one place located here: http://tinyurl.com/frc2022docs. This site contains all of our code since our founding in 2007 under the area called "Programming Documents" and it contains our documentation area which we are in the process of creating. We saw a need for the documentation from year to year because releasing the code isn't enough to teach people how to program it, so we are creating little tutorials to help with that.