RevRobotics new library seems to crash

117 views
Skip to first unread message

Charlie Peppler

unread,
Feb 9, 2021, 10:16:33 AM2/9/21
to vmx-pi
I just created a new WPIlib robot project in VSCode
from TimedRobot template, wrote some very simple
code to just start a motor on a SparkMax.

Old projects ran fine, but when I imported the new
vendordep from RevRobotics on this new project,
Java crashed.

I have copied the driver station log below, attached old vendordep and
new vendordep, and wanted to know how best to proceed.

Use old vendordep?  Ask someone to bring the dependencies
back in sync?

Any help/guidance would be appreciated.

Charlie

---log excerpt---
VMX HAL:  pigpio library version 69 opened. 
 VMX HAL:  SPI Aux Channel 2 opened with baudrate of 4000000. 
 VMX HAL:  Established communication with VMX-pi model 0x32, hardware rev 60, firmware version 3.0.422 
 VMX HAL:  Acquired navX-Sensor configuration. 
 VMX HAL:  Library version 1.1.237 
 Set VMX CAN Mode to NORMAL. 
 Server Running... 
 ********** Robot program starting ********** 
 java.io.IOException: SparkMaxDriver could not be loaded from path or an embedded resource. 
 attempted to load for platform /linux/athena/ 
 Last Load Error:  
 /usr/local/frc/third-party/lib/libSparkMaxDriver.so: libwpimath.so: cannot open shared object file: No such file or directory 
  
 at edu.wpi.first.wpiutil.RuntimeLoader.loadLibrary(RuntimeLoader.java:84) 
 at com.revrobotics.jni.RevJNIWrapper.<clinit>(RevJNIWrapper.java:43) 
 at com.revrobotics.CANSparkMaxLowLevel.<clinit>(CANSparkMaxLowLevel.java:38) 
 at frc.robot.Robot.<clinit>(Robot.java:31) 
 at edu.wpi.first.wpilibj.RobotBase.runRobot(RobotBase.java:231) 
 at edu.wpi.first.wpilibj.RobotBase.startRobot(RobotBase.java:348) 
 at frc.robot.Main.main(Main.java:27) 
 # 
 # A fatal error has been detected by the Java Runtime Environment: 
 # 
 #  SIGSEGV (0xb) at pc=0x75540cd4, pid=2629, tid=2664 
 # 
 # JRE version: OpenJDK Runtime Environment (11.0.9.1+1) (build 11.0.9.1+1-post-Raspbian-1deb10u2) 
 # Java VM: OpenJDK Server VM (11.0.9.1+1-post-Raspbian-1deb10u2, mixed mode, concurrent mark sweep gc, linux-) 
 # Problematic frame: 
 # C  [libvmxpi_hal_cpp.so+0xadcd4][thread 2670 also had an error] 
   spiGoA+0x238 
 # 
 # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again 
 # 
 # An error report file with more information is saved as: 
 # //hs_err_pid2629.log 

REVRobotics.json
REVRobotics.json

Scott Libert

unread,
Feb 9, 2021, 12:43:46 PM2/9/21
to vmx-pi
> SparkMax; Old projects ran fine, but when I imported the new

vendordep from RevRobotics on this new project,
Java crashed.
> Use old vendordep?  Ask someone to bring the dependencies
back in sync?

Hi Charlie,

Hope all is well; for now, you'll need to use the 2020 vendordeps (any perhaps the 2020 SparkMax firmware, I'm not sure).

Several projects are underway now, and our current plans are to release an update (to bring VMX-pi in synch with the 2021 WPI libraries and third-party devices) this summer.  You're welcome to be a part of beta testing that.

One of the major breaking changes with the 2021 WPI Libraries is the introduction of the new wpimath library.  Since with this issue the SparkMax library can't satisfy the dependency on libwpimath, it's possible that copying the linuxraspbian build of the latest libwpimath.so file (into the raspberry pi's /usr/local/frc/third-party/lib directory) from the WPI Library Maven Repository will resolve this dependency.  I don't think the .so file will get overwritten when new deployments of the robot application code occur.  However, this may just be the first layer of the onion so I'm not recommending this path.

My encouragement is to stay with the 2020 vendordep (and the 2020 WPI libraries). 

I realize this isn't the best news for you at this point, but it's the one approach that's sure to work.

- scott

Charlie Peppler

unread,
Feb 9, 2021, 10:38:02 PM2/9/21
to vmx-pi
Right now I'm simply teaching a high school student the basics of working with motors and sensors in Java, so I have no
need to move forward into untested territory.  I can stick with what works, as long as the Kauai Labs/Studica gradle scripts
don't move things partially forward into new libraries, and leave me in an inconsistent state.

I'm fine with staying with 2020 vendordep and WPI libraries as long as you guys will let me! (or give the OK to move forward onto 2021
with SparkMax libraries and firmware).

Scott Libert

unread,
Feb 9, 2021, 10:50:07 PM2/9/21
to vmx-pi
> I can stick with what works, as long as the Kauai Labs/Studica gradle scripts
don't move things partially forward into new libraries, and leave me in an inconsistent state.

I hear ya. :)  There are a lot of little pieces that all have to be lined up just right.  We'll keep everyone on the forum posted.

Reply all
Reply to author
Forward
0 new messages