Hello, my team is trying to make the move from labview to Java, or at the very least try and have both concurrently running for the experience at the least, however I am having some difficulties with this. I’ve tried using RobotBuilder and that isn’t working out how I expected. Obligitory helpful things listed below
This is the current iteration of the code using RobotBuilder, however the files that imported from RobotBuilder appear with errors in Eclipse
Errors such as XXX cannot be resolved to a type and other such things. This is the default code that was imported straigth from the RobotBuilder and it isn’t working.
Also whenever I try to export from robotbuilder it turns my cursor into a loading circle as you would expect but it stays that way virtually indefinitely. The project is able to be found in the directory I set it to but RobotBuilder still shows as loading.
Don’t use RobotBuilder. It encourages a lot of bad OO practices (such as most of the robot being declared and accessed globally), and doesn’t really save you that much boilerplate, anyway.
If you want your code to be flexible and easy to work with, I strongly suggest not declaring anything at all to be global (i.e. public and static), and instead to just pass instances of (mostly private) objects around as needed. It makes it much easier to keep track of the information flow of the program, which is important for implementing changes without breaking everything as well as for allowing you to re-use code later (which is an important thing that is seldom-discussed in FRC; too many teams essentially write their robot code from scratch every year, which severely limits their ability to build novel functionality).
I don’t remember RobotBuilder declaring anything Global, per se; it just created static pointers to all the subsystems in the CommandBase class. This isn’t intuitively obvious, but it’s also not horrible, either.
All the subsystems, actuators, and sensors are public static variables, which means that it’s impossible to keep track of where they’re being accessed from without reading literally all of your code, and that essentially no implementation details are meaningfully encapsulated.
It’s a recipe for code that one can very rapidly make “functional,” but is excruciatingly difficult to do anything nontrivial with.
Even if it were just the subsystems, I would advise against it.
The issue is probably JDK 9. Go back down to the most recent JDK 8 revision and it should work. Note that to revert, you’ll probably have to uninstall JDK 9, and may have to change the JAVA_HOME system environment variable. You can check the version being used by typing “java -version” into the command line.
The type that you aren’t resolving is relevant as it can tell whether that type is custom, should be coming from the JDK, or should be coming from WPILib. Can you give a list of the types that aren’t resolving? If it is a lot, you can just give a few.
Something you can look at while waiting for replies is rightclick your project and go to Build Path > Configure Build Path. You should see your JDK and WPILib in your Libraries tabs there if I’m not mistaken (But I’m not on a computer with an FRC dev environment right now).
That actually appears to be the problem, it appears that RobotBuilder isn’t exporting my Subsystems. I couldn’t tell you exactly what the errors are now as the source files for the project have gotten all cluttered with something else that exported there but I cannot delete them as I don’t have permissions to that section of the file system (for some unknown reason).
However do you have any idea why it could be that RobotBuilder isn’t exporting my subsystems files?
Not sure, but I would go with Oblarg and say don’t use RobotBuilder. If you start with one of the example projects you should be able to follow their examples to make your first simple robot project pretty easily.
I would start over with an IterativeRobot file, just all in one .java file to start. Get your very basic teleop driving working, then start breaking things off into separate classes and files from there, then expand your functionality. RobotBuilder is just a pain, and I think for simpler code iterative is easier to understand and follow than command-based.
You could, theoretically, do all of your robot code in just that one text file if you were patient enough, but that’s not a great idea for a variety of reasons (can’t collaborate as easily, no RobotMap, lots of searching and finding to change things, etc)