Maintaining pure python bindings is a significant amount of work, and as WPILib gains more features and as more and more third party vendors join FRC, it becomes harder to provide support for those features and third party devices. To reduce the amount of work required to maintain RobotPy in the long term, this year we’re moving back to a WPILibC wrapper (which is what we were doing pre-2015).
In the long term, there are lots of benefits to this approach:
I anticipate that python programs on the RoboRIO will have higher performance
We will be able to support more third party vendors with minimal effort
RobotPy will be less effort to maintain for our limited development team
Unfortunately in the short term, the wrappers are not ready yet. My current goal is to have RobotPy 2020 available by the end of the weekend.
RobotPy is a community project and only exists because FRC community members contribute! If you’d like to help out, join us at https://gitter.im/robotpy/robotpy-wpilib!
In the meantime, you really should be working on strategy for your team right now anyways! If you do need to do some prototyping, RobotPy 2019 still works great in simulation and on hardware (with the 2019 image).
Just an update, I was able to run a simple python robot program using the new WPILib simulation GUI tonight. Time for bed, but that means we’re most of the way there!
I’m hoping we can make a release for people to use very late tomorrow night, but there are some packaging and integration issues that need to be decided.
Ran into technical issues getting my Windows build VM to work (it works now!), so no release tonight as there are still significant integration issues remaining.
However, I have a lot more time Thursday night to work on this, so I’m optimistic about tomorrow night.
One of my team’s students pinged the 2019 version of this with a Pull Request for an update on the Simulator and was told that the Simulator would most likely go away in 2020. Does that mean that will not be a simulator this build season or next build season? I’ve investigated the Simulator for Java/C++ and while it has all of the basic functionality it does not have the robot/field view. I know that you are working very hard to get the 2020 version of the Python code base done, but we were curious as to what the official word on the Simulator part of this was going to be. A hearty-felt thanks in advance.
The plan is to use the new WPILib C++ simulator for RobotPy going forward, and it will be available with RobotPy’s initial 2020 release.
I do believe very strongly that teams need a robust simulator to do robot software development on, so once the 2020 porting is done I’m definitely going to take a closer look at how we can facilitate that (since my own team will need it!). It may be possible to use the old simulator, but I’m not sure. I expect the HAL dictionary to go away and replaced with something nicer that’s closer to what C++ exposes, but I haven’t looked too carefully at it.
My understanding is that the imgui UI toolkit that the WPILib sim uses is very simple to use, and it’s supposed to be extensible so that teams could theoretically write their own widgets. I haven’t looked myself at this yet.
Working through more issues, but it’s getting closer. There are some users currently testing it lightly in simulation, hoping for a wider release tomorrow night.
We have Windows wheels for wpiutil and ntcore uploaded to pypi! I’ve also tested them lightly on a roborio, and no problems there either. Unfortunately, no OSX support at the moment.
Unfortunately, once again, no wpilib – but it is functional for those who want to manually play with it. Since I’m still doing all the work, and there’s still lots of integration left, and I need sleep… not done tonight. BUT we do have automated stuff for uploading wheels to pypi now, so it’ll be easy to do the rest of this once the integration is done.
Non-roborio builds of some core robotpy pieces are now available for installation from pypi! If you’re on Windows and have Python 3.6-3.8, you can do this to try it out:
It’s best to do this in a clean virtualenv for now – you will need to uninstall pyfrc as it will conflict with the new sim. Once you have it installed, you can:
py robot.py sim
Please give it a try and let us know what breaks. There’s still a lot missing, but it’s coming soon:
commands
SendableChooser
Shuffleboard
Some new 2020 features
Tomorrow night I’ll push a roborio release, pyfrc/installer updates, and hopefully some 3rd party vendor packages.
Initial RobotPy for RoboRIO is out! Same features as yesterday, but they all work now. pyfrc and the robotpy-installer have been updated (thanks to Nick of team 5654 for that!). Still no OSX support, someone needs to step up and make that work.
I’ve pushed pyfrc as a beta release, so you have to pass the --pre flag to pip.
py -m pip install --pre pyfrc
Additionally, the RobotPy RoboRIO installer is no longer a standalone download, but it is installed as part of pyfrc.
Hello, I installed the new wpilib and pyfrc, and when testing a simple robot file I get the error: AttributeError: module 'hal' has no attribute 'isSimulation'
After other testing of installing and uninstalling dependancys, I have also recieved the error: module 'hal' has no attribute 'DigitalHandle'
Full traceback:
PS C:\Users\ETDev\Documents\Robotics\2020-Test-Robot> python .\robot.py
Traceback (most recent call last):
File “.\robot.py”, line 1, in
import wpilib
File “C:\Users\ETDev\AppData\Local\Programs\Python\Python38-32\lib\site-packages\wpilib_init_.py”, line 7, in
from .adxl345_spi import ADXL345_SPI
File “C:\Users\ETDev\AppData\Local\Programs\Python\Python38-32\lib\site-packages\wpilib\adxl345_spi.py”, line 14, in
from .spi import SPI
File “C:\Users\ETDev\AppData\Local\Programs\Python\Python38-32\lib\site-packages\wpilib\spi.py”, line 15, in
from .digitalsource import DigitalSource
File “C:\Users\ETDev\AppData\Local\Programs\Python\Python38-32\lib\site-packages\wpilib\digitalsource.py”, line 18, in
def _freeDigitalSource(handle: hal.DigitalHandle) -> None:
AttributeError: module ‘hal’ has no attribute ‘DigitalHandle’
Hi @eli3, that stack trace indicates to me that you have last year’s version of RobotPy installed.
Additionally, the ctre module has not been updated for 2020 yet. It’s possible that if you installed RobotPy first, followed by ctre, it would have uninstalled this years stuff for last year’s. The following should be enough to remedy the situation:
Hello! I am having the exact same error as above; however, I am running on an Arch Linux machine. I am running as follows: pip3 uninstall robotpy-ctre
And I am not exactly sure how to replicate the same thing for the second one. After doing this, I still receive the same error.
Must I wait for the 2020 Mac OS pyfrc to complete this? If I am going about this completely wrong, please let me know! Thanks!
On Linux, I think you can do python3 -m pip install --pre -U pyfrc if you’re using a virtualenv. If you’re not using a virtualenv, then you can add the --user flag to install.
Unfortunately, we don’t yet publish wheels for Linux, so you’ll need a compiler.