Team 254 is happy to share the code base for our 2015 robot, Deadlift.
This year’s software includes new features such as a test harness and simulator code to run the program on a computer, web-based graphing tools, constants editor, and autonomous selection, blocking autonomous routines, and a controller that calculates and follows a trapezoidal motion profile, on the fly. Please take a look at the following repositories:
While it does look rather accusatory (the comment by Treefaceman that is) I still find the observation interesting. I’ve always found one of the nicest things about any revision control (svn or github) was that it sped up our understanding of the stranger bugs:
#define true ((rand()&15)!=15)
by letting us know who wrote the code in which it was introduced.
If a team of 254s caliber is seemingly forgoing this utility I would personally like to know why. (Different internal system for tracking bugs? Mentors reviewing code before it goes on github? All just speculation of course.)
I like using the “blame” utility in SVN where beside every line of code adds a column of who wrote it and which revision of when it was added/edited. Actually though what really happens (from our workplace) is that each engineer is responsible for their own "module ", This seems to work best for us… there by… reducing the need for “blame”.
On a side note… what does that #define line of code do? Is that some fuzzy logic?
It was a prank a friend of mine played on me a few years ago (not while programming robots). Basically, true is true… Most of the time… It’s not as easy to detect as #define true false. We had a whole slew of these we did back and forth.
I was a programmer with 254 from 2011-2014. As others mentioned, a lot of the commits are done from Tom or Jared’s computer, but students and mentors write the code. 254 programmers usually followed pair/group programming practices, forcing students (and mentors who might be there) to check our work with each other, and a lot of work ends up getting done on a couple of computers. Additionally, when testing the code on the robot, you can only deploy code from one computer at a time, so writing on multiple machines is an unnecessary hassle most of the time.
Github isn’t designed for our practices of code writing. (Though a version control system that works for arbitrary groups of people committing as one would be cool). And for bugs, we usually just chased them down when we found them, getting help for them as needed.
Some questions (not a very advanced programmer, yet)
How do you run autonomous mode despite the looper? If you tried your approach on a normal iterative robot template, the loop would run on the wait commands, preventing it from advancing.
You need to generate splines to create paths for motion profiling, right?
What is the peacock motor?
Some more questions, but I’ll wait for answers to to these first.
run_sim.rb takes two arguments, the robot code directory FRC-2015 and the sim directory, Sim-FRC-2015. It sounds like you’re giving it only one argument.
Whats the license like for the code, specifically the stuff in the Simulated Robot Hardware repository. I would like to put some of that in the simulator side of the C# project if possible.
I added some license files to all the repos (MIT for all our stuff, BSD as some of the FakeWPILib is derivative of WPILib). Feel free to add whatever you see fit to your projects!
We run the auto in a separate thread. The main thread of the robot which handles iterative updates does nothing in auto mode because all of the marshaling done by the auto modes is done in another thread, and all of the control loops run in a different thread.
We didn’t use any spline paths this year. All of the control loops were 1d (elevator carriages, drive forward, turn in place). All of the moving subsystems shared a generic base controller which could be tuned for the properties of that system. The motion profiling was done on the fly (this is a much easier calc than generating spline-y paths).
The original concept for our can grabber was a system that had 4 individual telescoping arms (feathers) that would go out and grab each can in auto, all starting from the robot centered on the field. This made the robot look like a peacock, and the name for that subsystem stuck through iterations. A motor peacock is just the motorized can grabber assembly.
#2, the CAN-enabled Talon SRX was new to FRC this season, so we decided to stick with tried-and-true PWM in case there were teething problems. As it turned out, the CAN Talon works great, and I’d say there’s a good chance we use them next year.
#3, yeah. The WPIlib JAR we used was tweaked to enable interrupts and the hardware timer to work correctly in Java (basically we just finished some incomplete JNI work). The source of the modified JAR is in the lib directory. Garbage collection and the JVM still mean that we aren’t quite as reliable as a RT C++ thread would be, but it is pretty stable with our changes.