RobotPy SPARK MAX bindings

#1

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

REV SPARK MAX & NEO APIs & Info
RobotPy 2019 release
#2

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

#3

(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.

#4

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.

#5

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.

#6

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: https://trello.com/b/DOsaf6hW/spark-max-software
That may indicate there are further C++ changes coming and when so that updates could be coordinated easier.

#7

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.

#8

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. https://github.com/robotpy/robotpy-rev/pull/5 if anyone here wants to improve it.

#9

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

#10

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

#11

The motors and controllers arrived too late for us to test this evening, but I did install the driver on the Rio and it did so without error. The sparks and neos are all wired with connectors so we will test tomorrow. Regardless of the outcome, I will post results.

#12

Just got it working on real hardware! Set our front shooter Max to brake mode and it works exactly as intended. Now just to be able to get encoder readings…

#13

In case somebody was wondering, this is our 3-hour codebase that has it working: https://gitlab.com/utk-robotics/ri3d/tree/rev-can

#14

I have been tinkering around too.

It seems to work, however…

  1. I cannot deploy our code because there is no rev library to import. So py-3 robot.py deploy breaks
  2. I can ssh into the Rio and use REPL to interact with the sparkmax. The following statements seem to work.

    Import rev
    motor = rev.CANSparkMax(1, rev.MotorType.kBrushless)
    But, if I try…
motor.set(0.5)

I get no error, but the motor also does not move.

I wonder if this is related to how the drive system works with the driverstation.

Any thoughts?

Also, a small word of caution. If you install the whl, and then try to run a Java program that utilizes the sparkMax library, your Rio may lock up, and may need to be recovered from a USB disk.

This has happened to me 4 times in the last two days on two different Rios.

#15

I don’t think you’ll be able to run any motors unless the robot is in an enabled state. Probably a safety thing?

I just ran it normally in DS teleop and it worked similarly to PWM. PID controls were accessible over the USB-C programming interface, so I let the team take the robot as-is using the CAN driver to competition this weekend. (Ri3D demo competition, hoping we make it through the northeast blizzard…) Probably won’t be able to test new robotpy-rev versions until it gets back home next week.

#16

That is what I suspected. I did not have any other code on the robot so I could not activate teleop.

How were you able to deploy the code without the Rev library locally?

Good luck on Sunday.

#17

Initially I was going to give our roborio internet access and use the python3 setup.py install with the repo on the robot but the outreach people were already waiting on me to finish so I just used the pip whl package from the GitHub releases:

wget github/robotpy/robotpy-rev
scp/rsync it over
# on robot:
pip3 install file.whl
python3
> import rev
# works

I had to reinstall python opkg things a few times but eventually it just worked like that, ran the robot.py deploy --skip-tests and bam, it was running.

The setup.py on the robot has to download a few things and requires git, but I had already installed my linux dotfiles on the robot so that was already set up / ready.

#18

Thanks. I had no problem installing the whl (after figuring out how to do, thanks auscompgeek), and the

>> import rev

worked through ssh REPL.
Which, if anyone is trying to figure out is easy.
Just ssh in and in the terminal, type…

$Python3… And you get a REPL. Just like a raspberry pi.

I was missing the --skip -tests argument on deploy. I will try tomorrow durring our build session, but this looks promising.

I will am rooting for you all on Sunday.

#19

You can install robotpy-rev locally using pip.

#20

Thanks to @auscompgeek’s hard work, I’ve went ahead and pushed an alpha release of these bindings to Pypi and also to the RobotPy opkg feed, so it should be installable the same way that you install the CTRE bindings now. Please report any issues you have!

I have a documentation site set up, but we need to resolve an issue with one of our dependencies before it starts working.