This is my first year doing FIRST (I’m a 9th grader) and I am hoping to be a programmer for our team. Which sites are the quickest and best for learning Java Eclipse??
-I hope to learn Eclipse fairly quickly. How long would it take to learn the basics?
-What is the hardest part of Eclipse, if anybody knows?
-How much do I really need to know to code for the competition?
Thank you! If you want to email me directly, my email is shinegirl4Him@gmail.com
For FRC, you can pretty much learn everything you need to know through the screensteps documentation. Realistically all you need to know is how to create a robot project, and deploy the code to the roborio, which won’t take long to learn at all. If your team uses git, you can take more time to learn about the git integration, or there are a few other useful features that aren’t completely necessary to frc. Your team also might use robot builder, which would take some more learning in the screensteps. For me the hardest (or most annoying) part of eclipse is the git integration, which wasn’t particularly intuitive to use.
For coding in FRC, most programs will not use much more than the simple logic statements and general object oriented design. Once you have a good understanding of those, you just need to learn the wpi libraries, which has pretty good documentation and examples, so it isn’t too bad to learn.
So, Java is the language that your team probably uses. Eclipse is the code editor that many teams used, sometimes also called an IDE. Java’s not the easiest language, but it’s an alright choice for starting out.
> I hope to learn Eclipse fairly quickly. How long would it take to learn the basics?
Eclipse the IDE is easy to learn, it’s a fairly simple GUI. Assuming you’re talking about Java, though, probably a good six or ten hours of work and experimentation to familiarize yourself.
> What is the hardest part of Eclipse, if anybody knows?
Once again assuming you mean Java, probably the hardest part is going to be wrapping your head around the object orientation paradigm. Java is what’s known as an object oriented language. That means that pretty much everything is represented as some sort of object, each of which can have their own properties and different actions they can take. This can be pretty hard to understand at first, and unfortunately makes up nearly the entirety of robot code (everything’s an object, from motor controllers to the joysticks).
> How much do I really need to know to code for the competition?
That really depends on your team’s level of code. Some teams use a bare bones approach and have little outside of basic joystick-moves-motors code. Some, on the other hand, have sophisticated and complex code involving motion planning and computer vision. And don’t even get me started on 971, haha. As long as you know the general basics-to-intermediates of Java, you should be fine. However, what really takes time to learn is understanding different robot programming paradigms and techniques, such as the command-subsystem paradigm, how to utilize Talon SRX motor controllers, how PID (closed loop control) works, things like that.
Codeacademy’s Java tutorial is pretty solid: https://www.codecademy.com/learn/learn-java
This is a good resource for learning object oriented concepts: https://www3.ntu.edu.sg/home/ehchua/programming/java/J3a_OOPBasics.html
FIRST has a site that’s good for learning FRC-specific programming: https://wpilib.screenstepslive.com/s/4485/m/13809
One thing you should know is that unless you spend dozens of hours per week on learning code, working on projects, and getting senior students to help you, you should not whatsoever expect to be proficient at coding after a single year on the team, let alone the time before the build season. Most programmers take a good year and a half or so to get even to the level where I’d trust them to program a more intermediate robot themselves, and longer such for things like computer vision and motion profiling. However, after you put the time in, it’s an intensely fun and rewarding subteam that I’ve fallen in love with.
Feel free to ask any more questions or clarification!
For team 1025 we use www.codecademy.com and learn the basics then we go over the code from the last year to understand the libraries and ect… to make coe for the robot. I would suggest doing the same.
While screensteps is a good resource for getting started, be aware that some of the coding practices it promotes are really quite bad. The same holds true of RobotBuilder; I would recommend avoiding that tool entirely, for it doesn’t actually buy you very much and the boilerplate code it generates violates many important principles of software design. For example, the suggested approach to the command-based robot pattern involves a lot of global program state (all subsystems are global); global state is generally the enemy of comprehensibility and flexibility.
If I had any piece of advice, it would be to avoid learning merely “how to program.” Basically anyone can learn to make an FRC robot respond to joystick inputs in their language of choice. However, where a huge number of teams fumble is in ever getting past this point (this was certainly true of 449 for many, many years). The practices that work best for quickly and easily developing basic code are fundamentally different than those that are necessary to successfully develop more advanced code - it is not merely a matter of getting better at the same skills, but of learning a different skillset entirely.
What really determines a team’s ability to write nontrivial, value-adding code is how good they are at software design. Take the time to learn about common design patterns, and to reflect on which patterns match well to the FRC problem-space. Practice refactoring initial “proof-of-concept” code into a more permanent, readable, flexible form (this is probably the most-important single skill to develop, since it is very very hard to write flexible, well-designed code the first time you attack a new problem). Be wary of developing a “if it’s not broken, don’t fix it” mindset around software, because the concept of “broken” is multifaceted; often, code that “works” is not code that is well-structured or fit for future reuse. Always remember that any code that you can’t reuse is code that you likely will later have to rewrite.
Meh.
There’s a reasonably good paradigm in procedural/‘real-time’ programming to follow a specific order: 1.) read all sensors & inputs; 2.) perform state-based logic; 3.) set outputs once, in one place, based upon states. This paradigm caches potentially-expensive sensor reads and also ensures outputs aren’t overwriting each other. We learned it from Dave Lavery in our rookie year, and it’s served us well in our various implementations of it for over a decade. The non-command-based Screenstep stuff, from the (admittedly) little that I’ve read of it, seems to follow this paradigm.
IMO, the biggest impediment to following screenstep for learning is the need to have a live robot.
As a rookie programmer on a veteran team, you also need to become familiar with the programming model (sample, iterative, or command-based) that your team uses. Some teams also have libraries they have built on top of these; if you team uses one, you will also want to learn to use them.
This is very well put, and has largely been the problem I’ve run into trying to both learn and teach FRC software. There just isn’t a lot of documentation accessible to people who don’t know what they’re doing between “here is how you make a robot drive around” and “here’s the source code of the best teams in FRC”. Any resources people have on this sort of code structure stuff would be appreciated.
I’ve found, unfortunately, that there’s limited value to be found in reading software design stuff online, or at least in doing so exclusively - lots of the advice is dogmatic and conflicting, and there’s a shocking amount of disagreement around basic terminology. It really, really rates to find a professional software engineer to directly consult - they don’t have to be anywhere close to a full-time mentor, but just someone whom you can poke regularly for advice about code structure. I have a friend who works for google who has been absolutely invaluable to us in this capacity.
That said, the one online resource I’ve found most helpful is here:
The guy is writing about smalltalk, but basically all of the principles described are directly applicable to more modern OO languages - what’s more, he talks in detail not only about design patterns for code, but also about development practices, which are just as important (one of the biggest problems with software design advice is that a lot of it fails to appreciate the fact that it’s often totally impractical to write well-designed code the first time through, and so ideal design principles are often ideals to be iteratively worked towards rather than hard guidelines to be followed at all times; this is why getting good at code review and refactoring is so important). Admittedly, the site is (unfortunately) ancient and hard-to-navigate - I’d recommend starting with the “Big Ball of Mud” article.