robotpy / robotpy-ctre Goto Github PK

These are the CTRE SRX features that we need for mag encoder:

• getQuadraturePosition
• getQuadratureVelocity
• setQuadraturePosition
• set with velocity control mode

Looking at my team's code, I think all we currently need added in sim are:

• configSelectedFeedbackSensor
• setSensorPhase
• PIDF config (including selectProfileSlot)

CANTalonSRX.h has the parameter values. The two eMotMag_ flags. You have to use the scaleVelocityToNativeUnits function on the inputs and then use setParameter to send the value.

I'm testing with 2018.0.0.

Part of the traceback:

File "/home/lvuser/py/motortest.py", line 112, in updateTalonLog 
     self.outputVoltageLog.update(talon.getMotorOutputVoltage()) 
   File "/usr/local/lib/python3.6/site-packages/ctre/basemotorcontroller.py", line 154, in getMotorOutputVoltage 
     return self.getBusVoltage() * self.getMotorOutputPercent() 
 TypeError: can't multiply sequence by non-int of type 'tuple' 

Whenever setting ControlMode.Follower, the pyfrc tests fail with a KeyError.

$ pip3 install -U robotpy-ctre
Collecting robotpy-ctre
  Downloading https://files.pythonhosted.org/packages/03/fb/28651f0540edeed6eafcd6a7589dbc2e94dd99142cbc112041b1df8f47dc/robotpy-ctre-2020.2.1.tar.gz
  Installing build dependencies: started
  Installing build dependencies: still running...
  Installing build dependencies: finished with status 'done'
  WARNING: Missing build requirements in pyproject.toml for robotpy-ctre from https://files.pythonhosted.org/packages/03/fb/28651f0540edeed6eafcd6a7589dbc2e94dd99142cbc112041b1df8f47dc/robotpy-ctre-2020.2.1.tar.gz#sha256=02b98d4c9843011280d022b165dd9dfb6167d786fefecbbf32da32ca6c3a1938.
  WARNING: The project does not specify a build backend, and pip cannot fall back to setuptools without 'wheel'.
  Getting requirements to build wheel: started
  Getting requirements to build wheel: finished with status 'done'
  Installing backend dependencies: started
  Installing backend dependencies: finished with status 'done'
    Preparing wheel metadata: started
    Preparing wheel metadata: finished with status 'done'
Collecting wpilib<2021.0.0,>=2020.2.2.0
  Using cached https://files.pythonhosted.org/packages/ef/a1/08852fe60b2230176605a2b83c3a3d5f7cf92b51c996194fcd948eaeb8fc/wpilib-2020.2.2.10-cp37-cp37m-win32.whl
Collecting pyntcore<2021.0.0,>=2020.2.2.0
  Using cached https://files.pythonhosted.org/packages/8e/83/3c3c4744152bc780416782194c74923d2529b7875ebcd6b375a93c990468/pyntcore-2020.2.2.3-cp37-cp37m-win32.whl
Collecting robotpy-wpiutil<2021.0.0,>=2020.2.2.0
  Using cached https://files.pythonhosted.org/packages/df/67/b52502cb3fd62f316087dfadf4390122a774e0fb2e653100646fe0c1b042/robotpy_wpiutil-2020.2.2.2-cp37-cp37m-win32.whl
Collecting robotpy-hal<2021.0.0,>=2020.2.2.0
  Using cached https://files.pythonhosted.org/packages/d0/77/3cf21f6974d9452cc66da9e9b6def551b7ce8a43b6230bd1c5ebebc16dbb/robotpy_hal-2020.2.2.2-cp37-cp37m-win32.whl
Collecting pynetworktables<2021.0.0,>=2020.0.0
  Using cached https://files.pythonhosted.org/packages/ef/89/8947a4fe98a3f199271b16682834ed0338c248988e1ee0a85daa844c8ee4/pynetworktables-2020.0.2-py3-none-any.whl
Building wheels for collected packages: robotpy-ctre
  Building wheel for robotpy-ctre (PEP 517): started
  Building wheel for robotpy-ctre (PEP 517): finished with status 'error'
  ERROR: Command errored out with exit status 1:
   command: 'c:\users\connor barker\appdata\local\programs\python\python37-32\python.exe' 'c:\users\connor barker\appdata\local\programs\python\python37-32\lib\site-packages\pip\_vendor\pep517\_in_process.py' build_wheel 'C:\Users\CONNOR~1\AppData\Local\Temp\tmplvxotdps'
       cwd: C:\Users\CONNOR~1\AppData\Local\Temp\pip-install-s7n2t3f_\robotpy-ctre
  Complete output (8 lines):
  running bdist_wheel
  running build
  running build_py
  running build_gen
  running build_dl
  Downloading http://devsite.ctr-electronics.com/maven/release/com/ctre/phoenix/api-cpp/5.18.1/api-cpp-5.18.1-headers.zip
  100%Downloading http://devsite.ctr-electronics.com/maven/release/com/ctre/phoenix/api-cpp/5.18.1/api-cpp-5.18.1-windowsx86static.zip
  error: HTTP Error 404: Not Found
  ----------------------------------------
  ERROR: Failed building wheel for robotpy-ctre
  Running setup.py clean for robotpy-ctre
Failed to build robotpy-ctre
ERROR: Could not build wheels for robotpy-ctre which use PEP 517 and cannot be installed directly

I had an error while installing over pip. Looks like the url is malformed - this link works:

http://devsite.ctr-electronics.com/maven/release/com/ctre/phoenix/api-cpp/5.18.1/api-cpp-5.18.1-windowsx86-64static.zip

setCurrentLimit function, giving the current limit in Amperes.

enableCurrentLimit function, enabling/disabling the current limiting function.

9.3 in the software reference manual.

For example, this only shows a single CAN motor, even though they have different arbitration IDs:

import ctre
import wpilib


class Robot(wpilib.TimedRobot):
    def robotInit(self):
        self.talon = ctre.WPI_TalonSRX(0)
        self.victor = ctre.WPI_VictorSPX(0)


if __name__ == "__main__":
    wpilib.run(Robot)

https://github.com/CrossTheRoadElec/Phoenix-Examples-Languages

setNominalClosedLoopVoltage function, motor voltage to output when closed loop features are being used
disableNominalClosedLoopVoltage function, disables the nominal closed loop voltage compensation.
getNominalClosedLoopVoltage function, returns the currently selected nominal closed loop voltage.

Hello. While working on some robot code in RobotPy with the robotpy-ctre library, I encountered a strange bug that seems to work on the c++ and java counterparts, but not here. The code that triggers the error, at the bare minimum, is running setControlMode(CANTalon.ControlMode.Follower) on a CANTalon motor, and then setting it to follow another talon. The code runs through fine until it gets to initializing the simulator window. When doing so, the following is shown in the console (Using eclipse):

18:31:33:681 INFO    : wpilib              : WPILib version 2017.1.1
18:31:33:681 INFO    : wpilib              : HAL base version 2017.1.1; sim platform version 2017.1.1
18:31:33:681 INFO    : wpilib              : robotpy-ctre version 2017.0.2
18:31:33:697 WARNING : pyfrc.sim           : sim/config.json not found, using default simulation parameters
18:31:33:701 WARNING : pyfrc.physics       : Cannot enable physics support, C:\Users\empedemonte20\workspace\Potential\src\physics.py not found
18:31:33:705 INFO    : nt                  : NetworkTables 2017.0.6 initialized in server mode
18:31:33:705 ERROR   : wpilib.ds           : Joystick Button 1 on port 1 not available, check if controller is plugged in
18:31:34:331 INFO    : pyfrc.sim.ui        : pygame was detected, real joystick support loaded!
Traceback (most recent call last):
  File "C:\Users\empedemonte20\workspace\Potential\src\robot.py", line 52, in <module>
    wpilib.run(MyRobot)
  File "C:\Users\empedemonte20\AppData\Roaming\Python\Python35\site-packages\wpilib\_impl\main.py", line 121, in run
    retval = options.cmdobj.run(options, robot_class, **kwargs)
  File "C:\Users\empedemonte20\AppData\Roaming\Python\Python35\site-packages\pyfrc\mains\cli_sim.py", line 107, in run
    ui = sim.SimUI(sim_manager, fake_time, config_obj)
  File "C:\Users\empedemonte20\AppData\Roaming\Python\Python35\site-packages\pyfrc\sim\ui.py", line 95, in __init__
    self.timer_fired()
  File "C:\Users\empedemonte20\AppData\Roaming\Python\Python35\site-packages\pyfrc\sim\ui.py", line 416, in timer_fired
    self.update_widgets()
  File "C:\Users\empedemonte20\AppData\Roaming\Python\Python35\site-packages\pyfrc\sim\ui.py", line 492, in update_widgets
    extension.update_tk_widgets(self)
  File "C:\Users\empedemonte20\AppData\Roaming\Python\Python35\site-packages\ctre\_impl\sim_ui.py", line 51, in update_tk_widgets
    motor.set_value(self.data[data['value']][0].get_value())
AttributeError: 'CtreUI' object has no attribute 'data'

Started staring at the PigeonIMU stuff again (both here and in ctre-rs), and realised that we don't have an API to only get fused heading like in C++/Java.

We should probably rename the existing getFusedHeading method to getFusionStatus.

I get this error when I import WPI_TalonFX

This is a useful function for resetting all parameters of a talon to a known state. It crashes in the simulator right now. At least for us, it doesn't need to do anything in the simulator, just not crash.

Depends on #12

Depends on #12

I have something over at https://github.com/auscompgeek/robotpy-ctre/tree/legacy which will probably work? I'm sure some teams would appreciate this.

Depends on #69.

http://devsite.ctr-electronics.com/maven/release/com/ctre/phoenix/ for non-beta.

There's no source code nor offline installers/zips available for 5.9/5.10.

There is an offline zip for 5.8.1 though. Release notes mention a couple of API-level changes.

As reported by @ArthurAllshire .... need more details, and need to dig into this.

Oops.

Trying to use keyword arguments results in an argument mismatch error on config_kF and configSelectedFeedbackSensor at least, maybe more that I haven't tested. In the documentation the keyword names are given as (in config_kF) slotIdx, value, timeoutMs. On the robot they are arg0, arg1, etc.

I'll grab the stack trace tomorrow if I can.

https://github.com/CrossTheRoadElec/Phoenix-frc-lib/releases/tag/Phoenix_v5.7.1.0

Two major issues:

• There is now a CCIEXPORT macro used to add a visibility attribute to every CCI function prototype. It doesn't play so well with CppHeaderParser (although we might be fine with assuming what the return types should be). A workaround could be to replace all occurrences of CCIEXPORT with the empty string, but I don't think that's ideal.
• The timeoutMs, pidIdx, and slotIdx arguments now have defaults. This would preferably handled by the autogen stuff. Having blanket defaults would be fine, since Python has keyword arguments.

This are some of the last functions causing our team code to throw NotImplementedErrors in the simulator.

Apparently CTRE provides libraries that you can use to interact with the motors on an Raspberry Pi, and at least one user has reached out to see if these wrappers can be used to do that.

It should work, but someone would need to:

• Download the correct versions of the libraries (probably just changing the arch would be sufficient)
• There's a check to see if setup.py is ran on a roborio -- if you are, then it compiles the bindings, and if you aren't then it uses simulation. I don't know if we would want to autodetect an RPI environment... think we'd want to have some mechanism to specify that this particular wrapper should be used (or maybe by specifying a package extra via pip?)

Our team is really jealous of the C++ and Java teams. It would be really fun to play songs on our bot after important bugs are fixed :)

CTRE told me during the 2017 season that they were exploring an approach that would make it easier to create a third-party wrapper around their drivers. I anticipate that a small rewrite of this package will be necessary -- but it should be fairly straightforward to do.

I've reached out to them about the status of the new drivers.

Users might get a mistaken impression that the functionality doesn't exist -- whereas it just doesn't exist in simulation, but would work fine on a real robot.

Maybe NotImplementedError('this feature is not implemented in Simulation')? Or add a SimNotImplementedError class?

If you install robotpy-ctre via robotpy-installer, it will cause the simulated hal to be installed on the RoboRIO. We need to prevent that somehow, as it leads to really difficult to debug problems.

Will help catch errors for users.

I'm thinking the best way to go about this is with a decorator that uses the dynamically generated eval stuff found in hal-sim.

I'm trying to do Motion Profiling with 4 Talon_SRX's, 2 quadrature encoders and a pigeon_imu.
encoder 1 is plugged into talon_srx_1
encoder 2 is plugged into talon_srx_2
pigeon_imu is plugged into talon_srx_3
and talons 2, 3, 4 are set to follow talon one.

I'm trying to use only talon_1 for it's PID loop for encoders and aux PID loop for the pigeon.

Pretty much following this example from the java code: https://github.com/CrossTheRoadElec/Phoenix-Examples-Languages/blob/master/Java/RemoteClosedLoop/src/org/usfirst/frc/team4130/robot/Robot.java

But it seems like this function is not fully implemented yet in the python api. Is there a quick fix or workaround for this?

Working on it.

I cant seem to use the setPulseWidthPosition method on the WPI_TalonSRX class. I'm trying to use it to zero the position, but when I use it, it doesnt change a thing. Is there another function I should be using to zero the Pulse Width Position, or is there a problem?

setClosedLoopOutputDirection function, output direction in a closed loop scenario, either true or false

• configMotionProfileTrajectoryPeriod
• pushMotionProfileTrajectory
• processMotionProfileBuffer
• clearMotionProfileTrajectories

For some reason in the last week we've had issues reinstalling python-ctre on our computer. It seems to install onto the robot fine but we can't deploy.

When I try to use pip to install it, I get this error.

It seems it can't find that specific zip file on the CTRE website, but is that something we can fix on my end?

Thanks so much for fixing #36! Two other methods that would be great to mock would be configForwardLimitSwitchSource & configReverseLimitSwitchSource. (You can tell we're getting our sensors all hooked up for real instead of just in simulation... 😉)

Arg parsing is very inefficient (see #52) ... should change this in 2019 for compat reasons.

Currently one of the last functions throwing a NotImplementedError in simulator.
(we ❤️ robotpy!!)

CTRE calls _3, we call _2 (maintaining backwards compat). Looks like that's a poor decision, so might need to break backwards compat.

Reference: https://www.chiefdelphi.com/t/talon-srx-controlmode-motionprofile-works-controlmode-motionprofilearc-does-not/345660

In the new CTRE API, Falcon-500s have been added to the mix. Our team needs to be able to prototype with these motors soon, and right now the only option is another programming language.

Is the Falcon 500 implementation already underway?

You can find these motors here.

setSensorDirection function, either true or false to reverse sensor direction

I can't sim any of my robot code because of this function. I don't need it for the sim, but it would be a lot of work to rip out everything in my program just because it's not implemented in the sim. Is there a way to just force it to not throw an error, or to return [0, 0, 0] and print a warning or something of that nature?

The simulation should only allow changed values to be sent back periodically, or sample it or something...

https://github.com/CrossTheRoadElec/Phoenix-Documentation/blob/master/README.md#status-frames--how-to-tweak-them

There's a lot of new stuff it has that we don't currently support -- and they tweaked some of the class inheritance stuff too. These need to be implemented, but I'm hoping that none of them are critical -- so we're just going to push a 2019.0.0 release first, and get the rest of the stuff in a future release in the near future.

Main things that are missing:

• Argument defaults for pidIdx, slotIdx, and timeoutMs. (Are there any more that I've missed?)
• APIs for factory resetting and configuring every persistent setting on a device.
• API for synchronising quadrature sensor position to PWM sensor position.
• Various motor controller config APIs that were previously only available via raw parameters.
• BaseMotorController.setInverted() can now take an InvertMode enum.
• New motion profile streaming API.

Running pyfrc robot tests now end up taking about a minute or so, when they previously finished under 20 seconds.

I think having the simulated PID loop run every 10ms instead (similarly to the simulator) would be more sensible.