Hey ChiefDelphi members,
I am one of the primary programmers on our team. I have some experience with Java and am learning general Java techniques, but I am not all that familiar with FIRST specific programming. If anyone has some starter tips for me, I would really appreciate it.
Thanks in advance!
The thing that helped me learn the most was looking at other team’s code, many teams post their code on their websites or here. 1114 just posted their beta testing code to the whitepapers section here, and I haven’t looked at it yet, but I’m sure that it’s very good, I’d take a look at it.
I’m not a programmer however mind the relationship you have with your team and remember that what holds true in build season/off season is not true about peoples personalities in general. Most programmers on my team don’t like seeing me during build season cause that means I want some change to the code or contest what they have done, that doesn’t mean I hate programmers I just want a discussion going. Outside of that (hopefully) I think the programmers and me are on good terms. I don’t really know if there is a phrase for this kind of situation but if someone on a mechanical team or electrical team comes up to you and says “Its a programming problem” they don’t (or shouldn’t) mean “You are bad at programming”
Just my outside advice.
Also welcome to Chief Delphi!
I was a new programmer last year, and by the end of the season I programmed the whole robot in Java.
There is many team created resources out there currently, but the FIRST resources will become available at Kickoff. You can look at last years documentation here; it has good info on basic WPILib programming technique that won’t change with the new control system. 2015 control system documentation is here, but you can’t access it until kickoff.
I would highly recommend reading about Robot Builder, and using it to generate all of your code.
You will be tempted to pick the SimpleRobot template because it is very simple, but I would recommend using CommandBased because it makes autonomous programming much easier.
I will once again stress the importance of reading all of the documentation provided at Kickoff because everyone will need to learn the new control system.
If you have any questions feel free to pm me or email me at [email protected].
EDIT: Also make sure to follow this guide to install Eclipse before kickoff, so that you are ready to start programming immediately.
The simplest thing is (though it has already been stated) to look at others teams code as most teams post it on Github and CD. Also familiarize yourself with the FRC API. Our programming mentor’s answers to most of our programming problems is “check the API” (which of course is followed by much complaining as he already knows the solution but wants us to figure it out ourselves). If you have previous Java experience than programming an FRC bot shouldn’t be too much trouble. Also I recommend using the the Command Base template. Though it can be confusing at first it pays off in the long run especially when you want to reference code from year to year. When it comes to using that template for the first time the key is to read the comment code.
- start small and work your way up
- build every couple minutes to make sure that your program still compiles
- test your work as you go along
- select good variable, method, and type names. Don’t shy away from changing them if there’s a better name – that’s what the professionals do. It’s easy in Eclipse – right click on the variable name
- set up the control system on a board and test prior to robot completion
- keep your code organized and well commented
- use a version control system (free GitHub anyone?), and commit regularly. This allows you go to backwards in time if you break something (and you will break something)
- read the code of other teams
- post questions on CD
- use the same name in the program for a control as you do in the real world --e.g., “left drive Jaguar”. Put a label on the left Jaguar that says that.
- use constants in a single type for all of the port assignments (e.g., PWM1) and name the constants after the device. This allows you to go to one place in the code and see how things should be connected.
Comment!!! What doesn’t make a good programmer, at least in my experience, is being able to have complicated algorithm’s and methods and classes, but being able to come back to code you wrote at week 1, while you’re at the heat of a competition and understand what its doing and fix it. That’s the mark of a good program. Comments, nice variable names (not too long, but don’t try and shorten them to three letters. leftShooterClutch is better than lsc, for ex.) and encapsulation, so it’s easy to see as you start.
tl;dr comments, proper variable names, and encapsulation. Easily the most important aspects of beginning to program.
EDIT: Also, as MrRoboSteve mentioned, Github gives a free bronze account to any FRC team (5 private repos(?)). I would set that up now. So insanely useful, although a bit of a learning curve to get used to github. But version control is absolutely necessary also.
Most of that is just formatting for clarity. I don’t think it has anything to do with skill or showing the mark of a “good” programmer.
A “good” programmer will use every possible thing he can to make up for inconsistencies on the rest of the bot, and also go above and beyond what is expected by creating new features or failsafes in order to increase the output of the bot.
Oh don’t worry it is easy. Just look at other teams code and you should be fine. Also remember we will help you with any problems you run into. If you are good with java you should float into all of the first stuff just fine. That was me last year. I just kinda taught all of the first java stuff to myself as our main programmer coded it cause I wanted to learn it and by the end of the season I was our secondary program and did most of the auton code and some other teaks(btw I am head programmer now). I hope you do good and if you run into issue than don’t be afraid to post some code and errors to Chief Delphi.
You might want to look at the RobotBuilder video, then the playlist about building programs with RobotBuilder on this page:
http://wp.wpi.edu/wpilib/robotics-videos/
The videos are from last year with NetBeans and we are trying to update them to Eclipse versions, but aside fro the minor differences of development environments, everything else, including the program, is identical.
It describes building a robot with, coincidentally, a gripper for picking up objects and an elevator for stacking them on top of other objects. Really, the videos were made a year ago.
Another good tip: add new functionality piece by piece. It’s easy to write a large complex system, download the code to the robot, and see nothing happen, and have no idea what the problem is. Test each actuator and sensor individually before you try to do anything more complicated with it.
What I have to say has already been stated, but looking at other teams code can be extraordinary helpful, you may learn how to do stuff you didn’t know was possible, you may learn some shortcuts or other tricks as well. Additionally if you look at a more experienced programmers code you will find that it is more optimized, if you make an attempt to do everything in a timely and efficient manner you will have fewer bugs to find in the future.
As it has been said; take the programming in a step-by-step basis. it is near impossible to program the robot all in one go (believe me I’ve tried, and failed every time.) Work on each sub system, then pull everything together as you gain the knowledge to do it efficiently.
Lastly, don’t be afraid or frustrated, try something new, so long as the robot doesn’t destroy itself in the process there is no harm in experimenting. If you have to rewrite code in the process so what. It’s just some typing.
Good luck, and have fun with the hell that can sometimes be programming. 