Interrogating the CAN bus

can
java

#1

In year’s past, we were able to interrogate the CAN bus for the presence or absence of devices, and skip creating WPILIB objects for them if they were not present. We did this to minimize the amount of spam on the console if someone was debugging a project, but the CAN devices were not present in the test chassis.

This thread has the details; much thanks for Omar at CTRE for that.

Unfortunately, it appears that the edu.wpi.first.wpilibj.can.CANJNI.FRCNetCommCANSessionMuxReceiveMessage method used to sniff the bus has disappeared. Is it there and I just missed it, or will I need to come up with a new way to do the interrogation (I see a lot of useful looking methods in edu.wpi.first.hal.CANAPIJNI, especially readCANPacketLatest).

If the latter, has anyone done anything like this so far this season?


#2

It moved packages to


#3

Thanks! I missed that when searching that package. Code builds now, need to test when I get to school.


#4

When we implemented Phoenix Tuner/Diagnostics, I was thinking of your discovery use case.
@fovea1959

An possibly-simpler alternative is to send a “getdevices” command to Phoenix Diag Server from the RIO. Basically open a tcp socket to http://localhost:1250/?action=getversion, and look at the response.

https://phoenix-documentation.readthedocs.io/en/latest/ch06_PrepRobot.html#verify-the-robot-controller-http-api

You can also do this off the rio with http://172.22.11.2:1250/?action=getversion, or whatever hostname you want to use.

That will give you a formatted json list of all discovered devices. You can also do things like use the name of the Talon/Vic/Pigeon/CANifier to make decisions inside the RIO.


How to detect missing CanBus or attached device to prevent crash
#5

This is a good solution, provided we have Phoenix installed. It would be nice if it was integrated into WPILIBJ for those teams that just need it to check for the PDP or PCM…


#6

Note that Phoenix has to be installed in the roborio, not the PC, for this strategy.
Which you are likely to do if you are using talons/victors/pigeons/canifiers anyway or setting-ids at all.

… I agree, it was not my call. I’d be happy if Phoenix was pre-installed for you.


#7

Understood. Upon reflection, installing Phoenix is not an issue; we’ll want it installed on all our roboRIOs so we can assign IDs to Talons, etc.


#8

btw, this works great, but neither the previously used code nor the Lifeboat Tuner can find Spark MAX controllers on the bus :frowning:


#9

Out of curiosity,what equivalent method to verify CAN connections could we use in Labview?


CAN Device Check in LabVIEW
#10

Can you make HTTP requests from LabView and parse the (JSON) results?


#11

This whole use case came out of the CANTalon drivers spamming the console if we instantiate a Java object for a SRX or SPX when it is not present on the bus (same for a PCM or a PDP). These is a frequent situation for us; I have a couple of development RoboRIO systems that are sans motors; used for debugging other stuff (we’re a big team)

The folks over at REV wrote their drivers so that they just log once that the controller is not on the bus, and then are quiet. I don’t know what they do in the case of it’s present, but timed out.

If the drivers (for SRX, SPX, PDP, CPM) just log once that the Talon is not on the bus if it’s never seen, but then starts logging timeouts after it’s been seen once, then the spam problem goes away. That seems to strike a happy medium between spamming for systems that are missing the necessary hardware, and letting people know they have suspect CAN bus wiring if the hardware is present.

The enhancement for the SPX and SRX would need to be done by CTRE.

I took a look at doing it for the PDP and PCM in allwpilib, but the logging seems to be buried very deeply, perhaps in NI code. Where is the appropriate place to go for this side (again, it’s a 2019 summer project)?


#12

This sounds terrible given the mission-critical nature of FRC. If my devices are not on the bus, I want to know immediately. I don’t want to have to scroll up in the DS to find out my robot won’t work in the next match. Or worst, don’t notice at all until its too late (after match starts).

Make sure you explain this to your students so they don’t get accustomed to seeing DS errors as “normal”.

I think there are better ways to address your particular use case. Avoiding calling routines on hardware that doesn’t exist seems very reasonable to me.


#13

Omar, I agree. 'Twas a bad idea.

Having some log filtering would be nice (log4j or j.u.l), but that’s a WPI decision…