Thanks for another season of RobotPy! How can we improve?

Not only was the FRC season cut short this year, but this was definitely one of the rockiest seasons RobotPy has had so far — though I like to think that we ended strong! Moving to automated binary wrappers around C++ libraries was more challenging than I had anticipated, and lots of teams had lots of problems initially. I’m really sorry about all that trouble – and thanks to all of those who helped resolve those issues! RobotPy is a community project, and all of your help/input is welcome and needed!

Next season is our 10th anniversary – and my experience with the binary wrapper automation this year has made me really confident about next season. All of the work that has been done for this transition will continue to be useful for next year’s RobotPy, and as vendors and WPILib throw even more features at us it’ll be easier than ever for RobotPy teams to take advantage of them. I personally look forward to spending less time on boring maintenance tasks and more time on innovating.

Of course, nothing is perfect, and there’s lots that can be improved for next year. As it seems that I’ll have a lot of free time for at least the next month, I’m very interested to know:

  • What worked well?
  • What didn’t work well?
  • Are there things that are still confusing?
  • How can RobotPy improve for next year?

Thanks in advance for your input!


Thank you for this thread, and for all the work on RobotPy. We had a good year thus far with the software, and it is so robust, it is a bit mindblowing when we stop to think about it.
Here are our thoughts.

I enjoy the accessibility aspect of Python. I use Python in my courses with advanced students, and our other CS Classes use it with all of their students. Our school does not have an AP CS class, so there are no classes on campus that teach Java.

The fact that you are all so quick to incorporate new hardware and WPILIB functions (like Addressable LEDs, Kinematics, Odometry, etc.) and keep them updated is excellent. I know it is a lot to ask, but this is an essential feature for us. I also think the responsiveness of the dev crew is a huge help as well. Finally, one thing that may keep us from ever switching out of Python is how quickly the build and deploy process is. We used LabVIEW before, and I know this is not fair, but comparing the two, our deployment process went from 45 minutes at times, to practically instantly.

In a perfect world, we would love for the examples to be easier to find (maybe linked to in the docs like they do in WPILib), and the Docs be clearer and include tutorials like WPILib. To be honest, what we would really like, is for WPI to accept robotpy as official. Then, everything would be organized in the same way. This is especially important for vendor libraries where the paradigms are not consistent among vendors, WPILib, and robotpy. Another source of confusion of this was the conflict between the C++ source and the Java paradigm. There were times when we had difficulty figuring out how to call a variable, or send info into a class or method. However, now that we know how to access the help files directly, that has been a huge help.

As of right now, the only thing we struggle with is the how to access a specific Xbox axis or button through naming conventions, but enumeration works fine for us, and is a bit easier because they align with he Driver Station indicators. The way the season is going, we may have time for students to try their hand at trajectory programming. If this happens, we will probably have more questions.

I do not know that there is much that can be improved for next year beyond adding examples and documentation. A lot of the new documentation seems to list the classes and methods which is a huge help for us, but a team who struggles to find info on WPILib’s site may have difficulty juggling the two to know how to do much beyond the older wonderful tutorials you all created.

Updates are still a bit painful. This is not just a RobotPy issue, but it is more involved with RobotPy. We have to remember to update…
The RIO,
The Radio,
Each piece of vendor firmware
Each vendor library
The simulator (On machines we use the Sim)
The RobotPy version of each vendor library (We use 3: NavX, Rev, CTRE)
Every year, WPI and the vendors seem to release a huge update just before our first event (around week 3).

In addition, I wonder how WPI is going to roll out 2022 hardware and if there is an opportunity for the Dev team and some other teams as testers to help get robotpy up and running as quick as possible that build season. If this is a possibility, we do not mind helping (however, we would only be able to test code currently).

Thank you all for that you do for us. Robotpy has helped our team become significantly more successful. Since we adopted it, we went from spending the entirety of the first night of each event troubleshooting connection and build issues to actually being able to tweak our robot for the event and that arena.
~Mr. R^2


This is our third year using RobotPy. I really loved the sim the last two years, but I haven’t had a chance to get it working this year. That’s something on my todo list.

I think documentation updates would be the greatest help. Most of the documentation and examples are simple constructs… it’d be nice to see a more complicated example that used the simple constructs and augmented them. Maybe some “best practices” or recipes for doing various things would be good.

I’d like to help with wrapping libraries, adding in type stubs, etc. so some quick start documentation around that and other contributor tasks would be good.

I know it was a lot of work this year, but I do think this project is going the right direction and will pay off in the coming years. Thanks for all you guys have done to make coding with Python a viable choice!