We have just switched over to Java from C++ and are looking for simple Java code to use as a base for our second robot. Many of our programmers, including myself, aren’t very experienced with programming, because our last robot was mostly programmed by one person and as I said before, we used to use C++.
We are looking for code using:
-Pneumatics
-Xbox Controllers
-775 Pro encoders
-Grayhill encoders
However, anything helps. So if you don’t have one of these things, it should still help.
It depends on what you want to accomplished with your code. If you are interested in doing just TeleOp, then it should be quite simple. You can take a look at sample code provided by FIRST. If you are trying something more sophisticated or in autonomous, then the code will be a little bit more complex. I think FIRST also has some sample code on autonomous. I would start there. If you want to see other teams’ code, I am sure you will get into some relatively complex code. For example, our team uses relatively complex code but since most of the complexity is in our library, the competition code is relatively simple. You are welcome to take a look at it but if you are just starting to learn Java, you are better off starting with the FIRST sample code. https://github.com/trc492/Frc2017FirstSteamWorks/tree/master/src/team492
We are looking to do Teleop code with some simple autonomous. We are doing a simple robot to make sure that it is perfect and we get the experience without being overwhelmed. I will look into the FRC sample code and I’ll also look at your code.
If you’re looking for simple, while not Java, RobotPy has some unique features that make programming things like autonomous very easy. You can find a sample program here, and sample autonomous programs here
So my team attempted to program a robot last year with two people whose programming experience was limited to “we took intro to Java once” and “sometimes we write little scripts for fun”. Maybe we didn’t know where to look, but it seems like most of FRC’s programming resources for beginners is “Here’s how to build a simple robot! This is an iterative loop! You can put tank drive controls in here. Alright, that’s the basics, now have fun!” In short, it’s really inadequate.
It’s hard to make this kind of documentation and hand-holding tutorials for FRC, I don’t blame anybody for it being either hard to find or just not really existing. But there isn’t a lot out there that’s in between “here is how to get off the ground” and “here is what a good program looks like”.
If you want some really not so great code, here’s what we came up with. It’s essentially a single, 1300 line Java file, with no objects or classes or anything cool, but if you’re just quickly throwing something together it might give you an idea or two? You can definitely do better than this.
What kind of tutorials were you looking for? There’s a project called FRC ProgrammingDoneRight, and it’s basically a supplement to the FRC tutorials, with more advanced concepts. What kinds of things would you like to see in it?
I hadn’t seen that until recently, but I think the big thing missing is how to structure and use code for an entire robot. There’s lots on “here are the lines of code that let a PID loop work”, and that + what I learned before this season was enough to get us through the year, but the only things I’ve seen that really help you structure and lay out your code is RobotBuilder, which is itself pretty confusing if you don’t know what you’re doing or what your commands should actually be.
One aspect my kids had trouble with (and I had trouble getting too) is what exactly those functions should BE. The command examples seemed really tailored to autonomous mode - “Drive forward 10 feet” or “drop game piece from claw” etc. It was difficult trying to explain and determine what all of the different commands should be, before the robot was built, at the time we could run RobotBuilder. Like does every subsystem need an “open loop drive control via input” command and then everything else is a bonus?
I don’t mean to make this thread about “what my team / I struggled with in programming” - I’ll make my own thread if need be - I’m just trying to say unless you have some mentorship, doing it “right” isn’t totally straightforward just from the API and examples.
As always, make sure to read the screensteps documentation and examples. There’s also the YouTube playlist that Brad and Alex Henning did for RobotBuilder. It’s 5 years old now (!) but not much has changed since then.
Part of what I try to get inside my students heads is some classic OOP ideas, such as an object knowing, having, telling, being.
A Drive system **is **a subsystem, **has **motor controllers, can **know **and/or **tell **its speed and direction.
So, I help them break the robot into functional objects that become subsystems. We assign basic responsibilities to those subsystems.
We normally write a list of commands at that point, both for teleop and for autonomous (hopefully there’s some sharing going on) based on what the robot will be asked to do.
Once we have the list of commands, we look at what the methods the subsystems will need to execute those commands (and what properties the subsystems need to expose to help command decision making, e.g. termination).
One of our programmers put together a barebones java robot project to use in case of emergencies. We never refined it much, but it’s avaialble in our github.
It literally has just two subsystems: a tank-drive-style drivetrain and a climber. The goal was to make it as easily adaptable as possible to any random robot (eg, an offseason bot, or a prior-year robot) so it might serve your purposes fine.
If you want something a bit more complex, including pneumatics, encoders, and autonomous, check out our main robot code.
In twelve hours over the past three days, our small programming camp did a complete rewrite our 2017 teleop robot codeusing command-based java, with Gixxy, our founder and founding lead programmer, keeping us honest and on-model. We have an encoder wired to the RIO, two encoders wired to SRXs*, a composite variable-resistor touch-pressure sensor, three IR proximity sensors, and a limit switch, plus two streaming Lifecam cameras**. One of the neatest things about this is our use of the default command for each subsystem. If you have any questions about how this interacts with the hardware, I can definitely answer. I can also take many questions about the software myself, and get answers on those I don’t know.
These encoders are defined but not used yet; they will be in autonomous, to follow in coming weeks.
** currently we switch between cameras, but the switching is too slow (~3s). We’re going to stream both simultaneously, possibly at a lower resolution.
I’ll add to this and say that the API and examples give almost no insight into good practices for keeping code readable and easily extensible, much less reusable in later years. A student developing robot code on their own will likely have to screw this up a great many times and in a great many ways before they discover good practices for it - and given the four-year churn inherent in FRC, without directed mentorship it is unlikely that a team will develop this spontaneously.
This is very solid advice. The idea of “knowing,” in particular, is a rather abstract one but is absolutely crucial to keeping code from becoming a tangled, untraceable mess.
Unfortunately, I think a lot of intro java curriculum does a really poor job of preparing students for this. Students are often taught about encapsulation by being told that “it is a best practice to make everything private and use getters/setters,” but never made to work in any problem spaces in which doing this is actually important/helpful and thus they never really internalize what doing this is supposed to accomplish. In the moment, it will almost always seem like pointless overhead - and, if done blindly without a solid understanding of its purpose, it certainly can become that!
The ideas behind robot programming are generally pretty easy. Writing good robot code, on the other hand, is extremely hard.
I agree. Re-exposing all the needed interfaces of a sub-object without even QCing the inputs certainly looks like wasted time and effort both for the programmer and the computer, and doesn’t teach why you don’t just make the sub-objects public. A useful example would be something like software-implemented voltage ramping and/or current limiting, where the setSpeed() method might appear to set the motor speed to a given value from outside, but the object actually saves that value as the new **target **speed; another method or methods actually implement the ramping.
Yes, though the relevant idea here is not the ramping, per se. It is the usefulness of “hiding” the ramping, so that the code using the object with the ramp does not “know” that ramping is occurring. This means that it does not have to change if you decide to remove the ramping later, or change the way the ramping is implemented. Keeping the handling of the ramping private ensures that no external object can ever “know” about it, and thus is effectively de-coupled from it.
When students are simply told to “make fields private and use getters/setters to access them,” it is not at all clear that this de-coupling is the ultimate goal, especially if there are no obvious possible implementation changes for the feature being hidden (as is almost always the case in the simple programs students are likely to be writing in a java class). This often leads to one of two outcomes: the student might continue doing the “best practice” without any regard for actual future use (and thus blindly re-duplicate any changes to the private structure of the object in the public-facing methods), or the student may simply directly expose things as they become needed by external code. In neither case is the desired de-coupling achieved.
The value of proper control of the flow of information through a sufficiently-complicated program cannot be overstated. Unfortunately, programming curriculum seldom presents students with tasks in which programs become sufficiently-complicated. In this sense, I find that FRC presents a fantastic opportunity to make the value of these best-practices “real” for students.
