I’m always interested to hear people’s opinions. Good, bad, or otherwise, post it here!
I want to thank the RobotPy team for all of the great work that was done this season. I am a mentor that moved from Indiana to North Carolina this year. I left a Java based team (868) and my new team (5511) decided to move to Python this year (they had been using LabView).
The RobotPy team (I assume it is more than one person) should be proud of what they have created.
Hands down, this is the biggest selling point. Being able to run, test, set break points in code without having access to a roboRIO is tremendous. I wish all of the other platforms had this.
- Documentation. The installation and set up guides available at https://robotpy.readthedocs.io/en/stable/ are a tremendous asset.
- I have never had a problem setting up a system to use for RobotPy development (probably due to instructions mentioned above).
- Deploys are quick.
- Responsiveness to improvements and bug fixes. Your team put out several new releases during the busy build season, and while we would sometimes grumble about having to upgrade our installations so much, I very much appreciated your constant efforts and improvements.
- Mirroring the WPILIB frameworks. While the Command Based framework might not be ideal for Python, having a similar architecture available simplifies the process of moving between languages. Teams that understand the Command Based framework should easily be able to move between C++, Java and Python languages to experiment with the pluses and minuses of each.
- The “PythonDoc” comments and typing you included with your port of the WPILIB libraries. Taking the time to provide the Python equivalent of Javadocs is a huge time saver when using and IDE like VS Code. It is so nice being able to hover over a class or method and have a pop-up describing what it does, what parameters are required and what is returned.
- Example programs were useful, but sometimes out of date or lagged in updates. Since these are the least critical aspect of the project, this is understandable.
- The Python and Java run times can not coexist on a roboRIO. There isn’t an easy solution to this problem as this is due to the size of the Python and Java run time environments and lack of space on the roboRIO. This isn’t a problem if a team only runs one language, however, it is a pain when comparing implementations.
These comments are the things that I don’t care for when using Python for writing robot code. None of these items are related to RobotPy itself. These issues are related to using the Python language itself and my biases and ignorance coming from a Java based team. Some could argue that what I see as weaknesses are actually strengths.
- Very loose compile time checks. Python makes it very easy to deploy code with errors that won’t show up until run time. Stricter languages like C++ and Java would catch these errors during compilation and prevent the bugs from ever making their way onto the robot. This can be a real nightmare if the error in the code is buried in a conditional block that only runs in certain circumstances. For example, Janey tries to raise the elevator while the robot is moving fast, this rarely occurs and the code that handles this condition has an undefined variable that crashes the robot during the match.
- Lack of typing. While the Python language lets you suggest data types, it does not seem to enforce these data types.
- Using white space to mark blocks of code. It makes it very easy to write code that runs, but not the way the author intended (it’s probably my C/C++ days, but I miss the curly braces).
- Lack of primitives. From what I can tell, everything in Python is an object. So, doing math requires lots of object creation and destruction that can be avoided in both C++ and Java. From my rough testing Java is about 10 times faster at crunching numbers when using primitives when compared to straight Python code (I have a drive-py and drive-java project that has some rough performance testing commands at https://github.com/paul-blankenbaker/frc-2019). While this isn’t typically a factor as a lot of robot code is just glue with hooks to C/C++ libraries, our team was hit by this when implementing motion profiling algorithms in straight Python.
- Less support at competitions. There is no problem using RobotPy at competitions, just don’t expect to find any help trouble shooting problems (plan on being self sufficient).
Personally, I still prefer working in Java as it’s a nice compromise when considering (C++, Java, Python). The Java development cycle is fairly quick and syntax checking is strong.
However, my bottom line is that I would recommend that a team use the language taught in their schools when possible. Programming a robot is one of those activities where a student can see a direct relationship in what they learn at school and how it applies to the real world. Even if the relationship is backwards where students program the robot before taking programming classes offered by the school, it is still valuable.
Python and the RobotPy environment is an excellent choice for teams meeting the following conditions:
- You have a strong programming group with sufficient Python knowledge. Do not expect to find Python support at competitions. Instead, expect to provide Python support at competitions.
- You are not trying to execute too much code. Our team spent a lot of time this season trying to optimize their Python motion profiling code to get it to run faster. Much of this was due to I/O and library operations that all languages share. However, we feel that a portion of our performance issues were due to the speed of Python running on the roboRIO.
Our team will spend a chunk of this off season comparing robot development in Python vs. Java before making a final decision about what language to use next season.
Again, I’d like to express my thanks for all of the work done by the RobotPy team. I am amazed that you can find enough time to take on a project of this size and execute it so well. Team 5511 has really appreciated having RobotPy available for use this season.
Funnily enough, the C++/Java WPILib actually gained some very rudimentary simulation support over the last year (the backend is all there). It is actually possible to hit F5 in a C++/Java project in VS Code and have a simulation run in the integrated debugger.
Funnily enough, a large portion of the type hints were new this season. @TimTheGreat and I pushed fairly hard on getting in machine-readable type annotations (previously a lot of the type information was in the docstring - not fun for any static analysis like hovering over a variable in an IDE to see its type).
Huh, I never realised Python + the JVM was actually too large to fit on a roboRIO. Go figure.
This is one of the main motivating reasons for our pytest integration with the pyfrc fuzz test. The fuzz test is definitely far from perfect though.
pyflakes is a nice Python static analysis tool which picks up some common mistakes (such as potentially undefined variables). I set up my team’s CI to run pyflakes along with the tests; I don’t think we’ve had any code that was checked into master actually crash on the robot. There’s been a ticket on the backlog for a couple of years for integrating pyflakes into the pyfrc tests too: https://github.com/robotpy/pyfrc/issues/76
This is an intentional feature of the integration of type hints into Python - the run time cost should be minimal. I know of 4 different type checkers for Python now: mypy, Google’s pytype, Facebook’s Pyre, and Microsoft’s Pyright.
For the most part yes. CPython does have a small integer cache, but I suppose this doesn’t really help much if you’re doing floating point arithmetic.
If you’re doing any linear algebra though, numpy is a huge blessing. This also touches on the huge ecosystem of Python libraries as well - it’s great having convenient libraries a
pip install away, and I’ve never heard anyone say linear algebra is nice in Java
Java (and theoretically C++ if I finally finish it) teams can also use SnobotSim, a GUI based “extension” of WPILibs simulator packed with features and customization
Sorry Dustin that most of my simulator bumps happen in threads you’ve created…
Thanks for your detailed comments! I agree with many of your positives and negatives that you listed.
In particular, over the last several years, I’ve definitely come to appreciate statically typed languages, because it allows you to be lazier and not test your code quite so throughly. However, in FRC, only RobotPy had a usable simulator, and when I worked with a Java team last year it was maddening to not be able to use it (sorry @pjreiniger, I couldn’t get it to work last year… some eclipse issue) – I actually ended up creating some Python mocks to test things out before we implemented them in Java.
I haven’t had time to try Snobot this year.