RobotPy SPARK MAX bindings


I sat down for 3 hours tonight and put together these experimental hacked up RobotPy bindings for the Spark MAX using a perverse mix of the Spark C++ API and copies of wpilibc.

Unfortunately, I don’t have hardware to test this out with. Can someone else install it and let me know if it works?

  • Only works on a roborio, no simulation
  • Only thing that is implemented are the get/set functions

Finally, if this is something that you want to see done, please leave a comment on this thread. It’ll be a lot of work to put these together, and I’d like to know that it would get used.

More information and download at

RobotPy 2019 release

Thank you for this. This is exactly what I was looking for. While we do not have the hardware yet, I will let you know when we do and we test it out.

~Mr. R^2


(Ri3D Team Big Orange Robotics here)

We are using 5 Spark MAXs / NEOs on our robot right now, four on the drivetrain and one working our shooter angle. I’ll try to get some people together and we’ll try it out and report.

If I get as much time with the robot as I need I may be able to help a bit with the rest of the robotpy-rev code as I have 10 years of Python and 3 years of C++ experience, plus I’m used to writing code directly on roborio over ssh. I could potentially help fill in the remaining implementation based on demand.


Thanks for the offer! The primary thing I want to verify is whether or not my hacked up idea works on real hardware.

Once we’ve verified that my hacked up idea actually works, ideally, the SPARK MAX bindings can be autogenerated just like we do with CTRE (in fact, these quick hacks were so quick mainly because I copied a bunch of stuff from our CTRE bindings!). Then it just needs someone (you?) to take the time and massage the autogenerator stuff we have and make it work over there. Using the autogenerator is ideal because it makes it easier for us to keep up with the API updates in the future.


I recently discovered my team has invested in the SPARK MAX and NEOs, so I will likely make this a priority myself. I don’t currently have the hardware though - probably next Wednesday at the earliest.

I have faith that our hacky workaround works though.


Alright, I’m trying my best to find a time long enough to sit around with the robot lately while it’s mostly been traveling to local teams as a demo.

I’m planning on just dropping in robotpy-rev, importing, wiring, and seeing what happens. If you have other things you’d want to test let me know. Our lab space is only open at the college 900-1700 so I’m not sure on a time estimate yet.

The next priority for me would be encoder feedback / pid controls since we have one of the maxs driving our shooter aim.

I saw this from another member of our team:
That may indicate there are further C++ changes coming and when so that updates could be coordinated easier.


From the status of that Trello board, it doesn’t look like there will be changes to the C++ API itself in the near future. Any minor changes (e.g. additions to the API) are unlikely to drastically affect our bindings once we get the autogen stuff going.


Anyone done hardware testing yet? :slight_smile:

I did some autogen stuff last night (and @auscompgeek added some improvements), but I don’t think I’ll be able to do anything there for a few days. if anyone here wants to improve it.


I think ours are arriving today, and if so, as soon as I get to know the hardware a bit, I will try them.

When looking at the directions, I do not know what scp the whl means or how to do it. I assume that whl refers to wheel, but that is where my understanding ends.

Any advice as where to start?

~Mr. R^2


scp refers to scp(1). You can, of course, use an SFTP client if you prefer.