Our team has a summer swerve robot, and now that I finally have it for programming, I’m getting this message:
It appears on the driver station and in the Riolog every time I start up the robot or deploy code. Most of the time, the motors work just fine anyway, but sometimes they just don’t. When they do work, all the controllers appear in the REV Hardware Client, and when the motors don’t work, they don’t appear there.
Code is here: GitHub - firsttitanrobotics3767/2023-Swerve-Robot (It’s a bit messy right now, I’m working through testing and troubleshooting)
Is that every motor on your CAN bus? You probably have a wire loose somewhere along the CAN. Check over all your wiring, especially where the CAN goes to the RIO.
That is all the motors. I just checked all the wiring. Each module is wired in parallel, and the devices in each module are sequential. The fact that they’re in parallel makes me think that if there is something loose, it’s in the the wiring that connects all the modules to the main loop, but to be safe I checked all the wiring, and everything looks good. the connections are all tight and connecting to the right wires. Also, we have used the same CAN topology for the last two seasons and have never had this error.
This really does sound like a CAN wiring issue. The part about the REV H/W Client tends to rule out a code issue. CAN wiring is the nervous system or your robot – there are many threads here on this topic, it’s important and also easy to get wrong/suboptimal. It might help to post pictures, but the description you gave isn’t very reassuring, even if you have done things this way for several seasons…
FYI, the CAN ID for both REV’s Pneumatic Hub and their PDH is 1. If you have these on your robot, it’s probably a bad idea to use ID 1 for a motor controller.
You can easily determine can wiring problem by measuring each component in series and as soon as you cant then you know its broken at that component. put one probe at the start and move along each can device until it stops.
CAN IDs won’t conflict across devices (or vendors) [Source]. However, you do want to avoid the values that are there as defaults for new/unconfigured devices, especially with REV devices. This is because it can be a pain to assign device IDs when you have more than one device with the same ID, and it’s easy to replace a device with a new one before it gets configured.