CANCoders on CANivore, "CAN frame not received/too stale"

Hello, we are trying out swerve drive. We put our falcons, cancoders, and a pigeon 2.0 on a can bus provided by a CANivore. The wiring seems solid (all lights are happy), but we are getting a constant stream of errors about can frames from the cancoders not being received or being too stale.

These errors come in even when the robot is disabled. We tried updating the firmware on the CANCoders and updating the ctre vendordep in our code, but that didn’t fix the issue.

We are able to see all of our can devices and the canivore through Phoenix Tuner.

Bus utilization as reported by the driverstation hovers around 4%:

We double checked that termination on the CANivore was enabled. Also bus utilization on the CANivore is around 20%.

Link to code

Picture of driverstation with errors:

Can you verify you have proper termination at the end of your bus? I’ve seen some pretty wacky behavior if the CAN bus is not terminated.

1 Like

There should be a 120 ohm resistor terminating the CAN bus. The next time I’m at the lab I could verify that it is indeed 120 ohms (it’s actually 1 100 ohm resistor and 2 10 ohm resistors put together).

In Phoenix tuner, can you see what CAN loop the motors are on? Normally, the can loop to the RIO would have the name “rio.” The CANivore motors would have the name “Default Name”. In code, when you initialized the motors, did you give it a second parameter where you specified that the motors were on the “Default Name” loop? For us, it looks like this:
driveMotor = new WPI_TalonFX(driveMotorId, “Default Name”);

After re reading your post, I see it is just the CANcoders getting this problem. Also make sure you specify to your Pigeon and CANcoders that they are on the Default Name loop if that is the name you have.

Yeah I did that. I have a picture of what it looks like in Phoenix Tuner:

Can you point out where to find your CANcoder declarations in code? Also, if the Cancoders have LEDs, what color were they?

Check the cancoders have the latest firmware version too

Class should be in com.team2813.lib.swerve.controllers.steer. The class name is Falcon500SteerController. The CANCoder is created in the constructor. Also CANCoder LEDs were green.


Here is the LED chart from the manual of the CANCoder. If you are saying it is solid green, then the CANCoders seem like they are stuck in a field upgrade. Maybe retry it like it recommends?

Sorry, I should have been more specific. I mean it was blinking green rapidly. Not solid green.

Ah. CAN bus never detected. How many CANCoders do you have, and how are they connected to the CANivore compared to the other devices?

There are 4 CANCoders. Our falcons, CANCoders, and pigeon are all connected to the CANivore. Also, is the bright rapid green blinking noticeably different from the dim rapid green blinking? If the lights are rapidly blinking green brightly, then that would mean that the CAN bus is present.

Yeah, if it looks bright then its probably seeing the CAN bus. Can you screenshot your phoenix tuner showing the CANCoders?

I’m pretty sure the library you’re using doesn’t support CANivore yet. I didn’t see the can bus name anywhere in your code at least. When constructing any CTR device on a CANivore bus, you need to specify the name of the CANivore in the constructor.

You’ll still see devices in tuner, which indicates electrically your system is good, but since you’re still seeing ds errors I suspect the CANcoders aren’t getting constructed with the CANivore device name.

I’m pretty sure other teams have successfully used the SDS library with CANivore so I’d look around for that to solve the issue.

1 Like

Ah, that’s under a branch so it wasn’t obvious to me.
In that case it looks like you’re using the motor ID when constructing your CANcoder, but have different CANcoder IDs in your Constants.java file. You can make the CANcoder IDs match (same IDs are OK across different models) or update the code to use the explicit CANcoder ID.

Looks like that’s where the issue was. I updated the code to use the explicit CANCoder IDs and there are no more errors!