robotpy-ctre does not work standalone on an RPi

[virtuald]

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?)

[auscompgeek]

ctre._impl also does a hal.isSimulation() check. If you're intending to control real motor controllers on a CAN bus from a RPi, you probably don't want to have the WPILib HAL at all...

If I get a chance, I might have a go at building something. But there is a strong chance I will not have a chance to do this any time before bag and tag.

[virtuald]

The user who reported this was going to try it themselves. I've pointed them to this issue.

[stevenjowens]

Yup, that's me folks. I'm not using it for FRC purposes so I'm trying to avoid learning the entire FRC stack.

Right now the two things I'm trying to figure out are the opkg dependencies and the robotpy-hal-roborio package.

https://github.com/robotpy/robotpy-ctre/blob/master/develop.md

Has these requirements:

$ opkg install binutils-symlinks gcc-symlinks g++-symlinks libgcc-s-dev libstdc++-dev make python36-dev
$ pip3 install pybind11 wheel robotpy-hal-base robotpy-hal-roborio

raspbian doesn't use opkg of course, and none of those opkg package names are in the apt repos for raspbian. I haven't done much digging on this yet, it looks like binutils is already in raspbian, for example. Is there a doc anywhere that explains the dependencies in more detail?

robotpy-hal-roborio, similarly there doesn't seem to be much documentation explaining what this is, or what's involved in making an equivalent for raspbian. It looks like these are related to wpilib, which I don't need for my project (which isn't FRC, but is using some CTRE components).

[auscompgeek]

Those opkg dependencies are required to build for the roboRIO. You can ignore them, assuming you have a working C++ compiler and python3-dev installed.

The RobotPy HAL bits are used to:

• determine at runtime whether we're in simulation or on a real robot in ctre._impl (you will want to replace the __init__.py for that package)
• download the relevant bits for the roboRIO in setup.py (you should ignore this for a Raspberry Pi)

[stevenjowens]

Great, thanks!

I'm running out of steam at the moment, I'll give it a try tomorrow and post an update here.

[stevenjowens]

Looks like it's all building nice and clean. I submitted a pull request. Hope I did that right, most of my experience is with gitlab, not github.

rpi_robotpy_build.log

Now I need to figure out how to actually use it!

[auscompgeek]

Are you sure it actually builds and imports correctly for Raspbian? Judging by the PR you've opened, it won't actually work.

[stevenjowens]

Maybe not, which brings up the question of how I ascertain that it's building and importing correctly. setup.py sdist ran without any errors, what's the next step?

In any event, I'm fixing the things brought up on the pull request before I move forward.

[stevenjowens]

So I fixed those issues and it's building again.

Can anyone give me some pointers here? I'm not trying to get the entire FRC setup working here, just trying to code a fairly straightforward python script that controls a couple of motors via a Talon SRX.

I took a look at the code inside robotpy-ctre/dist/robotpy-ctre-2019.3.0.tar.gz

Specifically talonsrx.py and wpi_talonsrx.py.

Both of these import hal, and I think Dustin told me there's no hal implementation for raspberrypi. I had been hoping I'd be able to sidestep this, but now I'm not sure.

[virtuald]

The hal in TalonSRX is only used for usage reporting, so it isn't necessary if you're on the Pi. Not sure how to make it conditional -- but maybe for now you can just get it to work.

Unfortunately, the only way to really find out if what you've done works is to do an 'import ctre' on the RPi. That's because the build process creates a library, and the linking isn't resolved until runtime.

[auscompgeek]

I recall looking at upstream earlier this year and noticing that the usage reporting calls were removed from the high-level code, so it's probably fine if we do the same. I presume that usage reporting code was moved into the CCI library.

[auscompgeek]

Now that we're wrapping CTRE's libraries with robotpy-build, we should be able to make this work with robotpy/robotpy-build#37.

[auscompgeek]

I just landed #135, which means that this should finally be usable on Raspberry Pi OS! Unfortunately I don't have hardware to test the SocketCAN support with, but perhaps you might like to give it a shot @stevenjowens if you're still interested?

[auscompgeek]

Heh, I think @virtuald's vendor JSON parsing script may have regressed this for the 2023 beta. 🤷

[virtuald]

Feel free to make it suck less?

[auscompgeek]

Sounds hard, especially since CTRE aren't listing the ARM platforms in their vendor JSON.

[Sniklo]

Wait so was this resolved? And if so what is the procedure to make it work😂

[virtuald]

CTRE provides ARM wheels for phoenix6 in 2025. Refer to their documentation.

https://v6.docs.ctr-electronics.com/en/stable/docs/installation/installation-nonfrc.html and https://v6.docs.ctr-electronics.com/en/stable/docs/installation/requirements.html

[Sniklo]

Hmmm it’s my understanding that phoenix 6 doesn’t work with victors right?