My team this year is somewhat interested in using Python this upcoming season. A fear that a few of our fellow teammates have is that it isn’t officially supported by FIRST. Some of the reasons we are interested in using it are because 1) It’s easy to teach to new programmers, and 2) RobotPy seems to have a lot of useful features like the 2D simulator. We have in our previous years written our code in Java. What would you guys recommend and why? Thanks.
Python shill here. Honestly support at competitions isn’t that big of a deal, but only if you know Python well. I wouldn’t recommend it unless you know the language well and feel confident in your ability to debug your own code. It’s also important for sustainability that you have a mentor that knows python, or the ability to teach it to other students.
How many times in your first two years did you call upon other teams or volunteers to help with your programming? How big of a difference was that for you? Is there any reason to expect your team to be more capable in Python as compared to Java (e.g. a mentor who is an expert in Python and my java, Python is taught in your high school(s) but not Java, etc.)? If you wanted to take your programming, controls, autonomous abilities as a team to the next level, would that best be done with the assistance of other teams?
One big drawback to using an unsupported language is that other teams you are competing with and volunteers are unlikely to use the same programming language and may be unable to provide the same level of assistance.
From a competitive standpoint, we pre-scout for programming language. There could exist a scenario where we see a team’s robot and wonder whether we could add some simple strategic functionality. Help them write an auto that does XYZ, help them get their climber working, have them give their pre-loaded game pieces to a partner, etc. All of those are more achievable for my team if we happen to have a partner who programs in Java (same as we do). By using a less common language, you could close the doors on opportunities such as that or at least make that door harder to open.
The comments above are useful, and echo what you’ll find if you search for the other posts that people have posted asking the same question.
But hey – it’s the offseason still. Take a day or three, translate last year’s robot code into python, and compare/contrast the experience – and you should be able to test it at home using the simulator. The simulator is a huge advantage IMO, but I’m slightly biased. If you have questions, visit our gitter channel and you might be able to get answers.
Worth noting… there may be a simulator in Java/C++ this year… we’ll see if it materializes or not.
While Python is fairly well supported by members of the community through their documentation and Discord channel, I feel like Java is just a safer choice. It’s an officially supported language, and you will 100% be able to get random people at competitions to help you any time you have problems at events, which you probably can’t say for Python.
As Carl said, teams I have been on occasionally inquire to the programming language the team uses such that, after picking them, we can help them develop a simple autonomous routine for eliminations, or add functionality that they need to be successful. It’s not usually the deciding factor, but using Java (or really any FRC language someone on the team has experience with) may be a benefit in those tough decisions between two equal teams.
All that said, feel free to give it a try in the off season! I’ve heard that the Python implementation includes a simulator so in theory you could try this out now, without any hardware.
As with almost every post on the subject, I start by asking teams “What language are your mentors most comfortable with?” That should be your first choice unless a specific, compelling reason comes up to use a different language. If you are making the choice because you perceive one language as intrinsically “better” than another, you should probably not use the one you think is better. Because you probably don’t understand the languages as well as you think you do. There are languages that are better choices for specific applications and in specific circumstances. All of the available choices for FRC robots have strengths and weaknesses but are reasonable choices for the language to program. There is not one that is intrinsically a better language. The choice of appropriate language is heavily context dependent.
As for teaching, I have taught C++, Java and Python to students outside the context of FRC. While I tend to think that all other things being equal, Java is the easiest of the three to teach, having people experienced in the language should be the deciding factor.
The mentor knowledge base is really key, as the others have said. It’s also why we switched to Python three years ago. Our main programming mentor was moving away, taking the team’s LabView knowledge with him. I was also mentoring as a programmer, but I’m much more familiar with Python than C++ or Java. After looking at what was available in RobotPy it was an easy decision for us. We’ve been very happy with what we’ve accomplished with robot code since then.
The simulator is super handy, and we don’t even bother with the physics profile stuff. Just being able to execute the robot code without a robot and test the input/output is a huge timesaver.
Support at competitions hasn’t been an issue for us, but it’s hard to guarantee the same experience. We have problems on the field sometimes, of course, but I don’t recall having any where we opened up the robot code to have someone outside the team take a look.
As Dustin said it would be a good exercise to just write (or rewrite) robot code in the shop and see how the process goes for your team.
What do you intend to do with the simulator?
A rough test of the code? This might be useful.
Simulate an Autonomous Mode routine? Unless it models your robot, the field, the game pieces and the physics affecting them with sufficient fidelity, you might get some nasty surprises when you run the code on the real robot.
The simulator is useful for getting the general idea for autonomous. You can see if the robot goes in the general direction you expect it to, and if you set up the physics configs, you can get it to drive the correct distance as well. Each year we update it to accurately reflect the field layout, but there aren’t things like game pieces or collision detection. Still extremely useful when you want to program autonomous at home and fine tune it in the shop the next day.
I don’t think any reasonable person is going to run a simple robot simulator and expect that the code will work perfectly on the real robot as soon as it’s deployed. That’s not what simulators are for, and that’s not how people use them. The simulator allows the programmers to test the logic of their code, simple stuff like “oh, we’re driving that motor backwards” or “shouldn’t the second setpoint for autonomous be less than 200 feet from the starting position?”