JRE Crash with no CAN Bus Present with Spark MAXs

Not sure if anyone else has noticed this;
With nothing plugged into the CAN Bus port on the RoboRio;
When I create a CANSparkMax object, and try to access its encoder value with getEncoder().getVelocity() in a loop such as robotPeriodic, it floods the CAN TX queue and the program crashes with a somewhat unhelpful error.

Program stops crashing when something is plugged into the RoboRio CAN Bus port

RioLog Paste Here

Using Java, WPILib 2020.2.2, Fresh project, Freshly imaged Rio.

We will need the log file (eg /tmp/hs_err_pid5754.log), as this doesn’t have enough info. This will be lost when the RoboRIO is powered off. The file will change names each time. You can use a ftp client such as FileZilla to copy it off the Rio.

3 Likes

I have also seen this same error when we had accidentally disconnected our Spark Max controllers, but still had some TalonSRX controllers connected.

Try surrounding that code with a try catch statement

I’m not sure a try catch will help, as the function isn’t actually throwing an exception.

Will get the log file shortly.

1 Like

I’ve also found that without a CAN bus, attempting to use pneumatics will also cause the robot program to segfault when LiveWindow tries to update.

To be clear, I doubt the Talon SRXes were involved in your crash. This is something we rigorously test.

Our [CTRE] CAN actuators are designed to not crash rio-side software, even if there is no physical CAN bus. I can’t reproduce this, and have not heard of this before. Please send me the steps to reproduce this.

Attached is one of the many error log files. Not the same one as the original paste, but it’s very easy to reproduce…
hs_err_pid2127.log (41.6 KB)

Can you try posting like 5 more? That is crashing at some random point in native code, other logs might give something with some sort of symbol.

There’s 32 in the zip. The Rio recovers and crashes again every few seconds.
hs_err_logs.zip (287.6 KB)

I was able to reproduce with the following minimal code:

public class Robot extends TimedRobot {
  private CANSparkMax sm = new CANSparkMax(1, MotorType.kBrushless);
  @Override
  public void robotPeriodic() {
    sm.getEncoder().getVelocity();
  }
}

It looks like getEncoder allocates a new object each call.

public CANEncoder getEncoder() {
	return getEncoder(EncoderType.kHallSensor, 0);
}
public CANEncoder getEncoder(EncoderType sensorType, int counts_per_rev) {
	return new CANEncoder(this, sensorType, counts_per_rev);
}

If I change it to only allocate once, it doesn’t crash.

public class Robot extends TimedRobot {

  private CANSparkMax sm = new CANSparkMax(1, MotorType.kBrushed);
  private CANEncoder enc = sm.getEncoder();
  @Override
  public void robotPeriodic() {
    enc.getVelocity();
  }
}

The fix appears to be in work: https://trello.com/c/afvr4mPX/147-getencoder-getpidcontroller-etc-calls-re-create-the-object-on-ever-loop

Ozrien,

My note about TalonSRX’s was simply meant to add information to the main report, which said the problem occurred when “nothing plugged into the CAN Bus port on the RoboRIO”. I just wanted to add that the problem could still occur if you had other devices, such as the TalonSRX, plugged into the RoboRIO when trying to call getEncoder().getVelocity() on a Spark MAX.

Sorry I didn’t make that clearer.

Hmm, I can’t seem to reproduce this with a minimal robot program either. I might try to investigate my team’s code further.

I’m encountering a similar issue, but I created a new thread since I think it might be separate (not related to calling getEncoder() in a loop):

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.