RobotPy 2020 Old Commands framework available

Simulation:

py -m pip install robotpy-commands-v1

Roborio:

py -m robotpy_installer download-opkg commands-v1
py -m robotpy_installer install-opkg commands-v1

I don’t really have the time to test it throughly, but people have tried prior iterations of this and they seem to work. Let us know what you find!

This process worked, however I received an error afterwards. the error generally reads that it cannot find wpilib.robotbase, even though I have the wpilib library installed. Any suggestions?

Do you have a more exact error? There is a wpilib.RobotBase, but not robotbase.

Yes, that module. My apologies. Should I send a traceback?

That would be ideal. And code?

Ok, so I reinstalled some things, and now I am getting this error. Sorry to be throwing you for a loop here. Here is the traceback:

[coder@cougarcode1 pybot]$ ./robot.py test
Traceback (most recent call last):
File “./robot.py”, line 3, in
from commandbased import CommandBasedRobot
File “/home/coder/code/pybot/.venv/lib/python3.7/site-packages/commandbased/init.py”, line 1, in
from .commandbasedrobot import CommandBasedRobot
File “/home/coder/code/pybot/.venv/lib/python3.7/site-packages/commandbased/commandbasedrobot.py”, line 2, in
from wpilib.command import Scheduler
ImportError: cannot import name ‘Scheduler’ from ‘wpilib.command’ (unknown location)

If this helps, here is pip3 list:
[coder@cougarcode1 pybot]$ pip3 list

Package Version


a 1.0
atomicwrites 1.3.0
attrs 19.3.0
bcrypt 3.1.7
cffi 1.13.2
coverage 5.0.3
cryptography 2.8
importlib-metadata 1.4.0
more-itertools 8.1.0
packaging 20.0
paramiko 2.7.1
Pint 0.10.1
pip 19.3.1
pluggy 0.13.1
py 1.8.1
pybind11 2.4.3
pycparser 2.19
pyfrc 2020.0.0b2
PyNaCl 1.3.0
pynetconsole 2.0.2
pynetworktables 2020.0.1
pyntcore 2020.1.2.1
pyparsing 2.4.6
pytest 5.3.3
robot 20071211
robotpy-commands-v1 2020.1.2.0
robotpy-hal 2020.1.2.2
robotpy-hal-base 2019.2.3
robotpy-hal-sim 2019.2.3
robotpy-halsim-gui 2020.1.2.2
robotpy-installer 2020.0.1
robotpy-navx 2020.0.0
robotpy-pathfinder 0.2.6
robotpy-rev 2020.0.0
robotpy-wpilib-utilities 2020.0.1
robotpy-wpiutil 2020.1.2.2
setuptools 45.0.0
six 1.14.0
the 0.1.5
there 0.0.9
wcwidth 0.1.8
wheel 0.33.6
wpilib 2020.1.2.2
zipp 1.0.0

Given what you’ve shown here, that should work. Which platform are you on?

robotpy-commands 2020.1.2.1has important fixes, be sure to update! Not available for roborio at the moment, but I’ll push a build later tonight.

I am running on Arch Linux.

I’m not sure why it’s not working for you, but it might be a weird namespace thing? In particular, older versions of robotpy-build didn’t support namespaces… which is odd that you don’t have that installed.

What you might try doing is uninstalling wpilib and robotpy-commands-v1, then building wheels for both of them (pip wheel NAME), then installing the wheels directly (pip install foo.whl).

… we’re definitely going to be looking at building wheels for linux sometime in the near future, so this should go away once we get that figured out.

I fixed it! Thanks though. Not sure what I did exactly.

A variety of methods have changed as of 2020.1.2.2, see https://github.com/robotpy/robotpy-commands-v1/pull/3 for details.

Lots of progress with robotpy 2020, thank you all for your hard work!
I ported our team’s 2019 robotpy code to the 2020 release. I’m in a windows conda 3.8 env I made just for robotpy, and other than ipython I installed only the following:

pip install -U pyfrc --pre
pip install -U robotpy-commands-v1 robotpy-ctre robotpy-navx robotpy-rev robotpy-rev-color

which after a pip list currently gives me the following relevant packages:

pyfrc 2020.0.0
pynetworktables 2020.0.1
pyntcore 2020.1.2.2
robotpy-commands-v1 2020.1.2.2
robotpy-ctre 2020.0.1
robotpy-hal 2020.1.2.3
robotpy-halsim-gui 2020.1.2.2
robotpy-installer 2020.0.2
robotpy-navx 2020.0.1
robotpy-rev 2020.0.0
robotpy-rev-color 2020.0.1
robotpy-wpilib-utilities 2020.0.2
robotpy-wpiutil 2020.1.2.2
wpilib 2020.1.2.3

I can get the sim window up, I can deploy to the rio, and I can send data back from the spark max controllers, get data from the color sensor and the navx. Every number shows up fine on shuffleboard via putNumber. That’s all good, indicating that the old subsystems work fine. Most of my problems were in figuring out when to import commands, subsystems and buttons from wpilib.command, which basically involved changing a lot of wpilb imports to wpilib.command imports. All of my v1 commands work when called from standard JoystickButton bindings to commands_v1.

However, at the moment I have two problems:

  1. I can’t send a command to the SmartDashboard with putData. I’d like to still be able to call commands from the shuffleboard. Not sure the reason, if it is a v1 vs v2 thing but I would think both versions would be sendable. Trying a putData with a command that otherwise works on a joystick button causes “Windows fatal exception: access violation” in a way that is not easy for me to trace (on the sim this happens with or without the joystick plugged in, similarly on the rio):

(robo2020) cjh@mingw64robot$ python robot.py sim
11:04:17:588 INFO : wpilib : WPILib version 2020.1.2.3
11:04:17:588 INFO : wpilib : HAL version 2020.1.2.2
11:04:17:589 WARNING : wpilib : Core component versions are not identical! This is not a supported configuration, and you may run into errors!
11:04:17:589 INFO : wpilib : Running with simulated HAL.
11:04:17:590 INFO : halsim_gui : WPILib HAL Simulation 2020.1.2.2
HAL Extensions: Attempting to load: halsim_gui
Simulator GUI Initializing.
Simulator GUI Initialized!
HAL Extensions: Successfully loaded extension
Not loading CameraServerShared
Instantiating navX-Sensor on SPI Port 4.
Joystick Button missing, check if all controllers are plugged in
Default frc::IterativeRobotBase::RobotPeriodic() method… Override me!
Windows fatal exception: access violation

Current thread 0x000074a4 (most recent call first):
File “C:\Users\cjh\AppData\Local\Continuum\miniconda3\envs\robo2020\lib\site-packages\commandbased\commandbasedrobot.py”, line 15 in startCompetition
File “C:\Users\cjh\AppData\Local\Continuum\miniconda3\envs\robo2020\lib\site-packages\wpilib_impl\start.py”, line 94 in start
File “C:\Users\cjh\AppData\Local\Continuum\miniconda3\envs\robo2020\lib\site-packages\wpilib_impl\start.py”, line 31 in _start
File “C:\Users\cjh\AppData\Local\Continuum\miniconda3\envs\robo2020\lib\threading.py”, line 870 in run
File “C:\Users\cjh\AppData\Local\Continuum\miniconda3\envs\robo2020\lib\threading.py”, line 932 in _bootstrap_inner
File “C:\Users\cjh\AppData\Local\Continuum\miniconda3\envs\robo2020\lib\threading.py”, line 890 in _bootstrap

Thread 0x000036f0 (most recent call first):
File “C:\Users\cjh\AppData\Local\Continuum\miniconda3\envs\robo2020\lib\site-packages\wpilib_impl\start.py”, line 37 in run
File “C:\Users\cjh\AppData\Local\Continuum\miniconda3\envs\robo2020\lib\site-packages\halsim_gui\main.py”, line 34 in run
File “C:\Users\cjh\AppData\Local\Continuum\miniconda3\envs\robo2020\lib\site-packages\wpilib_impl\main.py”, line 186 in run
File “robot.py”, line 96 in
Watchdog not fed within 0.020000s
Loop (robo2020) cjh@mingw64robot$

  1. Trying to bind commands to our custom triggers (fairly standard axis buttons and POV buttons) also kill the sim. I switched to the built-in commands_v1 POVButton and was fine, but still not sure why ours dies, but my only insight is that they both die. I don’t have a ready solution for triggering on the right and left logitech button-axes as a button, so if an alternative is known please let me know. Our axis button code looks like this:

from wpilib.command import Button
class AxisButton(Button):
“”"
A custom button that is used when pretending an axis button is digital.
“”"

def __init__(self, joystick, axis):
    self.joystick = joystick
    self.axis = axis
    self.threshold = 0.03

def get(self):
    return self.joystick.getRawAxis(self.axis) > self.threshold

And trying to bind one of these dies in the exact same way as the putData.

It’s pretty fluid right now (forgive the mess, everything is in testing phase at the moment), but the oi code is at GitHub - aesatchien/FRC2429_2020 at robo2020

Any thoughts?
Thanks!

Hey @CJ_Hill the problem is that you don’t call the superclass constructor for some of your objects. We don’t currently have a good way to catch that, and as you’ve noticed the documentation is lacking… but working on this.

Anyways, here’s the diff of your code that no longer crashed:

diff --git a/robot/subsystems/navigation.py b/robot/subsystems/navigation.py
index dcc8931..b893c95 100644
--- a/robot/subsystems/navigation.py
+++ b/robot/subsystems/navigation.py
@@ -6,6 +6,7 @@ from wpilib import SmartDashboard
 
 class Navigation(Subsystem):
     def __init__(self, robot):
+        super().__init__("navigation")
 
         self.counter = 0
         # pain to debug this, so use the connected attribute as a debug flag
diff --git a/robot/triggers/axis_button.py b/robot/triggers/axis_button.py
index ce19a8c..09b764a 100644
--- a/robot/triggers/axis_button.py
+++ b/robot/triggers/axis_button.py
@@ -8,6 +8,7 @@ class AxisButton(Button):
     """
 
     def __init__(self, joystick, axis):
+        super().__init__()
         self.joystick = joystick
         self.axis = axis
         self.threshold = 0.03
diff --git a/robot/triggers/pov_button.py b/robot/triggers/pov_button.py
index 3d47ad5..1adde61 100644
--- a/robot/triggers/pov_button.py
+++ b/robot/triggers/pov_button.py
@@ -13,6 +13,7 @@ class POVButton(Button):
     """
 
     def __init__(self, joystick, angle):
+        super().__init__()
         self.joystick = joystick
         self.angle = angle
         self.threshold = 0.01

Thank you!
I really appreciate all of your time for the project and for inspecting my huge ask here.
I updated all the subsystems and triggers to make sure the parent init method is called. I now have my POV and axis buttons working exactly as in 2019 (when being sloppy with the parent init didn’t bite me!). Furthermore, I can send a subsystem to the SmartDashboard w/o killing the code, e.g.:
wpilib.SmartDashboard.putData(self.drivetrain)

I am still unable to get any of the commands to send to the dashboard for execution. Anything in oi like

from commands.intake import Intake
...
# simple intake command
wpilib.SmartDashboard.putData(Intake(robot, power=0.5, button=None))
# or 
wpilib.SmartDashboard.putData("Drive Forward", AutonomousDrive(robot, setpoint=None, control_type='position', timeout=6))

still ends the sim with a Windows fatal exception: access violation and also kills the code on the rio.
Any thoughts on why a command being used through a putData() call is crashing?

Yes, see https://robotpy.readthedocs.io/en/stable/2020_notes.html#common-causes

I’ll file a bug so that this gets addressed in the future for putData.

Thank you for pointing me to the updated docs. I didn’t see the common errors section when it dropped. The hint about retaining a reference to the object being called fixed it for me. Specifically, adding something like the following for each putData seems to have done the trick:

self.intake_command = Intake(robot, power=0.5, button=None)
wpilib.SmartDashboard.putData("Intake", self.intake_command)

That fixed the access violation caused by a putData() call.
Now our robotpy 2020 code can do everything the 2019 code could. Thanks!

Hi! Thank you for all the hard work you have been pouring into robotPy 2020 and also for helping us with our problems! We got our code to work on a test drive and no major problems. Next we needed to port our old program to 2020 but we have a problem with the scheduler when it runs getInstance().run(). It gives us this error:

We tried testing it by taking out self.s and replacing it with Scheduler, but it still did not work.
Here is our program:

The problem is that one of your commands does not override the required ‘isFinished’ function. We have a bug open to make the error message better.

It appears that the teleop command does not have a isFInished function.

I’ve fixed the terrible error message (https://github.com/robotpy/robotpy-build/issues/48), so future releases of the command framework will have better error messages when this type of failure occurs. You can probably expect a new release later tonight.