WPILib CommandScheduler + LLVM Usage

Hi,
I’m trying to port over the CommandScheduler from WPILib to use in a different project. This project will be likely running on a Raspberry PI, or some other ARM based SBC. The underlying framework will be using ROS, and therefore I’m using C++ or Python for most of the packages (I’m aware of third party support for Java in ROS, but I require the speed and the native ability of C++).

I’m running into some annoyances when moving over the CommandScheduler, namely, the dependencies that are required. I see in the source code that it utilizes LLVM for some utils, like hashmaps and vectors. I tried manually copying over the requisite files for specifically the command scheduler, but it’s pretty cumbersome when refactoring to fit my project. I’m assuming there’s an LLVM installer of some sort (though I haven’t been able to locate one, only the entire package with Clang included). If there is, where is it located, and what are the specific config options that I would need to use. If there isn’t, any suggestions?

Mentioning @Peter_Johnson as they may be the best person to answer this question.

IIRC correctly, RobotPy reimplements the command scheduler, so you can just take that if it works for you.

https://robotpy.readthedocs.io/projects/commands-v2/en/latest/_modules/commands2/commandscheduler.html#CommandScheduler

We import just the pieces of LLVM we need into the wpiutil library build here: allwpilib/wpiutil/src/main/native/thirdparty/llvm at main · wpilibsuite/allwpilib · GitHub

Any reason you can’t just bring in wpilib as a CMake project/dependency?

While that’s doable, the command-based implementation effectively depends on the entirety of WPILib (e.g. it sits at the top of the entire library stack) and they probably don’t want to pull in everything.

That’s actually an idea I didn’t think of, thanks for the suggestion. I think I’ll likely stick with C++ as the CommandScheduler will still require pretty much every WPILib dependency regardless, and I’d rather have the execution speed of C++.

I see… is it manually refactored to work with the WPILib code structure? Not sure why but my VSCode editor isn’t offering any refactoring options, though C++ is known to not have the best options for that.

Yeah, that’s pretty much exactly it.

I’m not sure what you mean by refactored. We have a script (in upstream_utils) that copies the pieces we want from LLVM upstream and applies a bunch of patches, including changing the namespace from llvm to wpi. We didn’t want LLVM as a full dependency, we need it to compile cleanly with all of our warning flags etc, and we need to change the namespace to avoid runtime ABI conflicts, particularly on Linux where it’s possible for Mesa to pull in LLVM libraries.

just curious, why would you need commandscheduler for a ros based project?

1 Like

oh, that makes a lot of sense. I’m entirely new to C++ (learning it specifically for this project), so I’m new to the concept of namespaces. Or, I guess more accurately, not the concept so much as the terminology. From my understanding, it’s essentially the same as packages in Java.

For the patches, do you just apply all of the scripts found in allwpilib/upstream_utils/llvm_patches at main · wpilibsuite/allwpilib · GitHub or is there a more specific process?

Thanks for the help!

There is a Python script in upstream_utils that applies other changes in addition to the patches. You should not need to run it yourself, the resulting files are in git (which I linked previously).