Interrogating the CAN bus

fovea1959 · January 8, 2019, 7:33pm

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?

Thad_House · January 8, 2019, 7:35pm

It moved packages to

github.com

wpilibsuite/allwpilib/blob/master/hal/src/main/java/edu/wpi/first/hal/can/CANJNI.java

/*----------------------------------------------------------------------------*/
/* Copyright (c) 2016-2018 FIRST. All Rights Reserved.                        */
/* Open Source Software - may be modified and shared by FRC teams. The code   */
/* must be accompanied by the FIRST BSD license file in the root directory of */
/* the project.                                                               */
/*----------------------------------------------------------------------------*/

package edu.wpi.first.hal.can;

import java.nio.ByteBuffer;
import java.nio.IntBuffer;

import edu.wpi.first.hal.JNIWrapper;

@SuppressWarnings("AbbreviationAsWordInName")
public class CANJNI extends JNIWrapper {
  public static final int CAN_SEND_PERIOD_NO_REPEAT = 0;
  public static final int CAN_SEND_PERIOD_STOP_REPEATING = -1;

  /* Flags in the upper bits of the messageID */

This file has been truncated. show original

fovea1959 · January 8, 2019, 7:44pm

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

ozrien · January 8, 2019, 8:00pm

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.

fovea1959 · January 8, 2019, 8:43pm

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…

ozrien · January 8, 2019, 9:06pm

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.

fovea1959 · January 11, 2019, 7:21pm

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.

fovea1959 · January 26, 2019, 8:00pm

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

Tom_Line · January 26, 2019, 9:07pm

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

fovea1959 · January 27, 2019, 4:52pm

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

fovea1959 · January 27, 2019, 5:10pm

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)?

ozrien · January 27, 2019, 5:33pm

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.

fovea1959 · February 9, 2019, 1:29am

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…

system · April 6, 2020, 1:45pm