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%:
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.
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?
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.
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.
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.
