Unable to Initialize the VMX HAL library from a WPILib Java Program

[Noah Mollerstuen]

Hi everyone, this is Noah Mollerstuen. I'm working with my robotics team to build an underwater robot using the vmx-pi as the primary processor. 

We're using the WPILib's command based robot program structure. I'm able to deploy to the vmx-pi, and to connect to it with the driver station. I've even been able to control a servo with a Joystick using WPILib's standard Servo class. However, it looks like to use the CAN bus, it looks like we need to use the vmx-pi HAL library. When I try to initialize the 'com.kauailabs.vmx.VMXPi' object, it fails to initialize because another process is already using the pigpio. The PID it claims is using the library however, is the PID of the java process itself. Looking at the logs included below, it seems that the VMX HAL library is initialized successfully before the WPILib program even starts. When I try to initialize the library again within the program, the two conflict. What is the proper way to use WPILib with VMX HAL? Is there a way to disable the automatic initialization of the library? I should note that I can run the Java HAL example programs without any issues. If there is any kind of example program or template for using the HAL library with WPILib that would be ideal. Thanks for any advice.

- Noah Mollerstuen

Software Captain for FRC Team 1157

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

 VMX HAL:  Acquired navX-Sensor configuration. 

 VMX HAL:  Library version 1.1.237 

 Set VMX CAN Mode to NORMAL. 

 Server Running... 

 ********** Robot program starting ********** 

 Default simulationInit() method... Override me! 

 Default simulationPeriodic() method... Override me! 

 NT: server: client CONNECTED: 172.22.11.10 port 55460 

 Initialize! // This is a print from my program

 2020-05-12 20:25:28 initInitialise: Can't lock /var/run/pigpio.pid 

 VMX HAL:  Error initializing pigpio library. 

 pigpio library already in use by process java 

  (pid=605) 

 VMX HAL:  Unable to establish communication with VMX-pi circuit board via Raspberry PI Aux SPI Channel. 

[Scott Libert]

Hi Noah,

Your project sounds very interesting.  Using the CAN bus underwater is something I haven't heard anyone talk about yet.

>  However, it looks like to use the CAN bus, it looks like we need to use the vmx-pi HAL library

The VMX-pi HAL is already being initialized by your robot application; that's why when attempting to open it directly from your application, you are receiving the "already in use" message.

The software is acting exactly like I'd expect it to - the issue is the VMX-pi HAL Library is being instantiated twice - which is not supported.  But there's a better way. :)

Since you are already using the WPI library for your application, you should use the WPI Library-provided CAN bus interface, rather than directly use the VMX-pi HAL.

WPI Library provides the "CAN" class for just the propose - so if you directly need to access the CAN bus, use the WPI library CAN class - not the VMX-pi HAL.  Internally, the WPI Library CAN class will use the VMX-pi HAL.

Additionally, if you are using the REV Robotics or Cross the Road Electronics devices, you can potentially use their libraries for accessing the CAN bus, rather than writing code for each CAN message itself. Information about that is here.

Cheers,

- scott

[Noah Mollerstuen]

Hi Scott!, 

Thanks for the quick reply! Because FRC in-person events are cancelled, my team is joining the MATE ROV competition for the first time. It's definitely a new set of challenges!

We're using some speed controllers which FRC doesn't support (the Kotletta 20s from Holybro), which definitely complicates things. Please correct me if I'm wrong, but it looks like the CAN class you linked only works for device which conform to FRC's can spec. We tried using the CANJNI class for lower level access, but attempting to read messages from the CAN bus produced a segfault from within the native interface that was pretty much impossible to debug. We're thinking of just switching to pwm, which is not ideal since we'll lose information like the current draw of each speed controller.

Thanks for your help.

- Noah Mollerstuen