Development on REVLib Wrapper Library

Technical Programming
, , ,
1

Motivation

Hello! I’m Asa from team 1155. We love REV’s hardware, but this year we, among other teams, ran into many issues and limitations with REVLib, and want to work around these to write more stable code for future years. However, a library to accomplish this cannot be effectively maintained and developed by one team, as it would quickly become defunct.

Technical

The contents of this library would likely include

  • seamless support for real and simulated sparks
  • cleaner API
    • not 1:1 with REVLib
    • removes access from smart motion, for example
  • lazy periodic frame configuration (@Amicus1’s idea)
    • only use period frames from sensors that users access
  • working configuration, synced burn flash
    • this comes from an issue where burn flash is a blocking call and nondeterministically ignores configuration calls

One other thing to note is that the library would merely wrap REVLib, it would not interact with their JNI directly to avoid unintended usage and bugs.

Ideally, features here would be upstreamed into the actual library until this is no longer needed, but currently REV’s software does not provide the required reliability and features that a competitive team needs to succeed without obscure knowledge and workaround code.

Would anyone be interested in developing, using, or maintaining this library? In addition, are there any features or issues that your team ran into that you’d like to see?

2 Likes
2

We’ve already kinda started doing that on our team. First started from the need to be able to easily mock the hardware devices for unit testing, and now also for a variety of other functions as well, including implementing logging via AdvantageKit.
Our latest work on this is here: GitHub - lasarobotics/PurpleSwerve

2 Likes
3

Asaaaaa maybe if we annoy rev enough they’ll make a proper sim lib, but I don’t mind helping design and support one, Java and rust I’m not doing a c++ support system

2 Likes
4

While it probably wouldn’t be included in the library, the AdvantageKit logging support is very interesting. I also like the design with a single wrapper class.

1 Like
5

I think “seamless” support for real and simulated sparks is difficult if you want to integrate with WPILib physics sims. Much of our sim setup is plumbing applied output to the sim and updating the values the feedback sensors would be reporting.

6

The possible ControlTypes are

kDutyCycle
kVelocity
kVoltage
kPosition
kSmartMotion
kCurrent
kSmartVelocity

Assuming we don’t allow SmartMotion, SmartVelocity, or Current, the rest shouldn’t be too bad to simulate. Voltage simulation is the simplest, where we would just input the voltage into a state space model. Duty cycle simulation would use the same method as voltage simulation, but we would account for the available voltage. Position and velocity PID are more complicated, as we don’t have access to REV’s source code. However, it may be possible to do so by converting the gains into units compatible with the WPILib PIDController and physics sims and then updating them multiple times per tick.

1 Like
7

We actually do, at least their PID impl from when they wrote the docs. It’s exactly what you would expect, tbh.

8

It’s C++ and doesn’t attempt simulation, but https://github.com/Jagwires7443/Scrappy/blob/master/src/main/include/infrastructure/SmartMotor.h and https://github.com/Jagwires7443/Scrappy/blob/master/src/main/cpp/infrastructure/SparkMax.cpp solve the other problems you’ve raised (and support almost all SparkMax/NEO functionality). The header file could even wrap smart motors from different vendors in a nice, serviceable, vendor-neutral API. It wouldn’t be a big deal to add JNI to something like this, FWIW.

9

I was also thinking of possibly using Trapezoid Profiling as a control mode to replace smart motion. Since the trapezoid profile can do essentially the same thing as smart motion but with a closed position loop. I don’t have much experience with simulation so I’m not sure how easy it would be to simulate.

I really like the idea of a REVLib wrapper, as I find some parts of REVLib to be very complicated (having a separate class for PID control and encoders).

With some more ideas and planning I would be willing to help with this.