2022 RobotPy Feedback

Technical Python
#1

The RobotPy project transitioned to primarily python wrappers around C++ in 2020… and it’s fair to say that like many other things in 2020, it was a bit rough. I like to believe that we’ve ironed out most of the kinks at this point – but without your feedback it’s really hard to say.

Did RobotPy work for you this year? Was it terrible? We would love to hear your feedback: good, bad, and the ugly.

PS: Is your team using RobotPy? If you haven’t already, add your team to the RobotPy community page (or you can view it on our website)!

1 Like
#2

We (team 6517) have been using robotpy exclusively for several years now. The only issue we have is the slight delay at the start of each season for updated robotpy to become available. I understand why there is a delay, but it sure would be nice if robotpy could become a “first class citizen” in the FRC/WPILib programming world someday.

1 Like
#3

The bottleneck is developer availability. An influx of volunteers can change the landscape pretty quickly!

2 Likes
#4

We’ve been using RobotPy since 2019 (Java before that). We transitioned to the commands2 framework this year. Everything worked very well in 2022. Nine SparkMaxes / Neos, a navx, a PCM and the new rev PDB all work well on the roboriov1 and no problems receiving object data from the pi 4B sending back locations derived from the hub and ball cameras.
Thanks to robotpy it becomes easy to keep the robot project in one (relatively) easy to learn ecosystem - we made a dashboard with PyQt, our image recognition runs on opencv-python on the wpilib rpi image, and we run training and plot our telemetry with Jupyter notebooks.
Many thanks to the devs for making robotpy and responding to our questions throughout the season.

2 Likes