The other day, we were sitting around talking about how to best approach the problem of making sure that every robot at an event can cross the line in auto. We considered the idea of a task force that could go to each team, learn their code, and help them write an auto, but quickly realized that we don’t know c++, LabVIEW, Python, or C#. Then it hit us, there’s also teams out there that don’t know Java and we could make a repository of Java Commands that cross the line in auto.
So what if we took it even further? What if we all worked together to make a library of robust, well commented, well organized code that could help any team, with any drive setup, in any language? Teams could develop cross-the-line autos, test them, and add them to a repository for everyone to use. We could even extend the concept even further and add autos that cross the line, then drop a cube if they’ve reached the right side of their switch.
You’ll notice that it only has a few Java CommandBased autos in there for now, but the hope is to build up a complete library that any team can use to add to their own code, or to help others.
If you’d like to help, please place your tested and commented code in an appropriate folder and submit a pull request. Then feel free to use any of the code in the repository to help you get that extra RP!
One thing to keep in mind: not “everyone” who uses Java/C++ uses the command-subsystem framework. I’d recommend including some more modular code for iterative and timed robots. And a team smart enough to adhere to the good OOP practices of command-base are probably not the ones who need help.
That’s kind of the point. We’ve been doing command based Java for so long that we don’t know how to write iterative or timed based code without a ton of work on our end. And we’re sure that there are plenty of teams out there feeling the same way about command based Java.
I put a folder in the repo for LabVIEW code, which I’m the LEAST familiar with, but I think GitHub hides empty folders.
Personally, I really like this idea. In fact, it is something i have been working on personally in the past year. (Although having help from other teams would make it significantly easier.)
However, I would suggest different sets of code for each language. (So for every class made in java, an identical class would be made in C++) this in my opinion would simplify things. There would also need to be standalone methods for teams using an IterativeRobot project.
Though it would probably be easier to “finish” 1 language at a time…
One thing to consider though, is instead of writing “working” robot code for this season, we could make a command (or method) that takes as an input the diameter of the wheels, the distance you want to travel, an optional gyro sensor, and an optional encoder value. Then use these to determine how far the robot has traveled.
If we standardize this type of method/command, everyone should be able to at least drive forward consistently every year.
Just starting with the drive train, there is a lot that needs to be done. For instance, what about turning? Or turning while moving forward? Or trying to reach a position on the field relative to the robot in the quickest way possible? These are all things that rookies could use to get a jump start with auto programming.
I am seriously dedicated to this project, so if you want to expand the scope of your project to beyond just this season, please reach out to me about this.
I have experience in java, c++, & python (less python experience though). But I can help with issues with those if you like.