1126 Reference Manual and Competition Code

[IGM]

This has been my fourth year on team 1126, my third consecutive year on software. I have always taken pains to fully integrate myself into the code-writing process, but I know that it will not last. When I go, I have to hand over the torch, so to speak.

For many years, our team has taught our students by word of mouth, by wading through undocumented or semi-documented code, by giving random tasks and implementing solutions. There were no documented examples to go on, no repository of implemented functions, and only a few scattered comments to read if we ever wanted to re-implement a feature.

Well, consider this post to be handing over the torch.

Our high school requires that our seniors undertake a major task, and this year I strove to document our code. I mean *really* document it. During the project, I strove to include as many documentation comments as possible, later I compiled a reference manual for the code, and provided explanations and examples for many programming techniques our team used. Some techniques developed over two years, some three, some dating way back before I was ever a student. Set on paper. Documented.

But if the point is to educate, then why be selfish? I've consulted with the mentors on our team, both software and not, and decided that there are enough people on these forums that would like real examples, not just explanations. Would like some explanations, not just some code tossed at them.

We're providing both. Attached in this thread is a word document containing the documentation of this year's game, our robot hardware, our software techniques, and our major robot subsystems. Also attached is our Finger Lakes competition code, which currently sits deployed on our cRIO in a box somewhere.

If you're interested in what we do and how we do it, need an example of how to implement something, or are just interested in what our team can do, it's all here.

If there is any one person out there who will read this post, delve into our bits and extract something useful from it all, then I will consider this mission accomplished.

Until then, I remain your faithful servant.
~Eric Rock, FIRST Team 1126
- Software Lead

P.S. Thank you to all of those who contributed to both this manual and our code. A special thank you to my project mentor, Tim.

[Lalaland1125]

Wow, that autonomous code is pretty impressive. Never thought of creating a sort of mini-language to help code autonomous.

[Spectare]

That autonomous code IS very interesting, it kind of reminds me of logo, but with commands to fire and such.

[joelg236]

Very impressive code. I appreciate you posting it along with the software manual. This is extremely useful to new programmers, and I will no doubt keep this for new programmers next year.

[gixxy]

I agree. Very nice and informative.

I will be using this to train our recruits for next year.

[Tom Line]

I think you'll find that many of the top teams use a script or command based auto system.

We switched over to it for the first time this year. The flexibility it gives you is astounding.

In 2011, we had a 'standard' state machine autonomous, where changes required you to go in, change portions of the program, and recompile each time. That resulted in a horrible failure where we were on the practice field trying to complete 2-tube-auto but could not because we would only get one or two repetitions of program - deploy - run auto each time due to the field time constraints.

In 2012, we went to a script system. We took pointers from teams like 33 who were gracious enough to post their code.

As a result, changing autonomous is as easy as changing a comand or number in a text file, and clicking 'save'. The widget we built ftp's it to the robot, and the robot program re-reads the auton files each time it executes auto-mode so it updates any changes. Writing an entirely new autonomous routine literally takes a minute. No new programming, just a text file.

It's worth the time to spend an offseason working on it.