Working through CAN controller issues

[nelson...@gmail.com]

I've got some code working but now trying to connect to CAN devices (VictorSPX, PCM) and having some issues there.  I don't seem to have issue connecting and deploying code, I have had a working PWM controller and camera, so far.  

I've tried to follow along for CAN controllers.  It is a previous robot, and I've tried doing the FRC lock reset for 3 victor spx's, in including the UnmanagedJNI code.  The JNI code insertion seems to immediately disable and lose robot comm when the robot is enabled.  I continue to get CAN Timeout errors.

I think the bus is okay, as the devices are all flashing orange.  I should have the IDs correct, but that brings up another question.  Are you able to reassign or check devices IDs, through something like Phoenix Tuner, when connected through the VMX-PI?  I've ran the diagnostic server and it appears to complete okay but no devices show.  

Likewise, I haven't been successful to connect to the PCM.  

[Scott Libert]

>  I've tried doing the FRC lock reset for 3 victor spx's, in including the UnmanagedJNI code.

In addition to removing the FRC lock, it's very important that the RoboRIO is not on the CAN bus after the unlock, because it will immediately cause the device to be locked again.  More info here.

We've never tested some locked and some non-locked devices on the CAN bus at the same time, if you have four victor SPXs (one for each drive axle) it makes sense that all 4 should be unlocked. 

I'd recommend starting simple with one and only one Victor SPX on the CAN bus, and building things up from there.

> The JNI code insertion seems to immediately disable and lose robot comm when the robot is enabled.  I continue to get CAN Timeout errors. 

Sounds like the robot application is crashing.  Have you seen any logging in the driver station logs you can send us that would provide more information what's occurring when the robot is enabled? 

In some cases, the error doesn't make it all the way back to the Driver Station.  You can also find the internal logs on the Raspberry Pi, in the /var/local/kauailabs/log directory; these logs are always appended to each time the robot application runs.

These should help indicate what the problem is, because they'll have a stack trace if some sort of exception is being thrown.

> Are you able to reassign or check devices IDs, through something like Phoenix Tuner, when connected through the VMX-PI?  I've ran the diagnostic server and it appears to complete okay but no devices show.  

No, you will need to use the standard procedure (RoboRIO) to use Phonenix Tuner.  They're the only CAN motor controller vendor that doesn't have a direct USB-attached tool to configure the motor controller.

You'll need to make sure the firmware version matches the Phoenix library version - you need the 2020 FRC version of firmware.

After you've verified the IDs and firmware vesrion, take the RoboRIO off the CAN bus, FRC unlock the CTRE devices, then power up the system.

> PCM

I'd recommend focusing first on getting the motor controllers working first.

CTRE has guided us in the past that non-competition PCM firmware was necessary to use the PCM w/out RoboRIO, so we may need to sort through that.

[Bradley BeMent]

> No, you will need to use the standard procedure (RoboRIO) to use Phonenix Tuner.  They're the only CAN motor controller vendor that doesn't have a direct USB-attached tool to configure the motor controller.

Is there any workaround available on the VMX-pi to allow CAN IDs to be assigned to CTRE motor controllers?

The " FRC CAN-based devices " section of the online VMX-pi documentation does not say anything about this issue, which is pretty significant for my use case.

[Scott Libert]

At this time, there is one other workaround that's documented by CTRE, as discussed here:  https://phoenix-documentation.readthedocs.io/en/latest/ch06b_PrepLinuxRobot.html

This involves running the Phoenix Diagnostics Tuner on the Raspberry pi, which accesses the CAN bus via a software driver interface known as "SocketCAN".  CTRE recommends (in the documentation referenced above) the open-source CANAble device; a quick check online indicates there's a USB-to-CAN adapter available for $29.

The SocketCAN interface is currently the only supported API usable on Linux by the Phoenix Diagnostics Tuner - and VMX-pi does not implement the SocketCAN interface.  The SocketCAN driver architecture is quite different from the VMX-pi platform library architecture and our analysis indicates it'd be quite complex to implement SocketCAN directly on VMX-pi.  Perhaps in the future an alternate interface can be developed so Phoenix Diagnostics Tuner can directly access VMX-pi, but if it does, it's a ways off.  We have been in discussions w/CTRE regarding alternative solutions but have no plans at this point.  

Let me know if you end up taking the route of using the CANAble device; in this case, we could acquire one too in order to perhaps provide some support, and we'd be happy to document the approach for others who might have your use case.

- scott

[James Taylor]

I would like to add that you can also use the Hero Development Board to update the ids and firmware for the CTRE system. The only downside is that you need a USB-A to USB-A cable to talk to the board, which I think is a significant design flaw(not a common cable). 

This is what I currently use to set the ids' for use outside of the roboRIO.

[Bradley BeMent]

Thanks everyone for your suggestions!

It should be as simple as using a simple CAN tool to query the CAN ID of a single connected motor controller, and then sending a single CAN message to that controller to change its CAN ID. Assuming the motor controller is designed sensibly and If the required CAN messages were known, a raspberry pi or any linux system or environment with a usb-to-can adapter supporting socketcan should be able to do this using the can-utils package. A simple program for the VMX-pi could also be written to do this. However, in my experience humans seem to inherently reject simplicity when more complicated solutions can be devised, so there may be some elaborate protocol required to change the CAN IDs.

Instead, I followed the approach outlined in the link that Scott provided and installed a bunch of Windows software on a windows laptop that then downloaded more specialized software to a networked raspberry pi with a usb-to-can adapter, that then (eventually) communicated with the software on the windows laptop to ultimately have the raspberry pi send a couple of can messages to the attached motor controller to change its CAN ID.  Rube Goldberg, but it seems to have worked for me at this point, although I have not yet moved a motor with the controller.

[Scott Libert]

>   If the required CAN messages were known, a raspberry pi or any linux system or environment with a usb-to-can adapter supporting socketcan should be able to do this using the can-utils package. A simple program for the VMX-pi could also be written to do this.  

Unfortunately when it comes to the CTRE motor controllers, the CAN messages required to retrieve/assign the IDs to the devices (or anything else) are not public.

VMX-pi can currently access CTRE motor controllers for motor control purposes by implementing a Phoenix "CAN Provider" API.  But that API isn't used by the Phoenix Diagnostics Server.

One thing that might perhaps help is to indicate to CTRE your desire to configure/tune their motor controllers on the VMX-pi platform; I've found Omar and Jacob to be very helpful; if they were to create some sort of user-mode API for implementing a CAN provider (something we've discussed but it hasn't been a high priority for them yet), we'd gladly take advantage of it to help out folks like yourself.