Hello! We’re currently facing issues with our SPARKs connecting in our CAN Bus. Our CAN bus setup starts at the RIO, runs through 11 Sparks and a Pigeon, then terminates at the PDP. When we turn on our robot, some of our SPARKs don’t show any lights for beat while others sporadically flash yellow. During this time, the PDP lights are red, indicating it’s not receiving any CAN signal. Eventually the SPARKs will intermittently flash magenta and the problem will resolve itself: all the SPARKs will flash magenta, the PDP will flash green, and both the Pigeon and the PDP will show up on Phoenix Tuner. This whole process of stabilizing can take from 30 seconds to a minute. The status light on the RIO turns off relatively fast, so I don’t think it’s an issue with the code taking a long time to deploy/initialize. The sporadic yellow flashing doesn’t seem to be an error code —it resembles the flashing that occurs when you short can wires on a SPARK, but if there was a short, it shouldn’t fix itself with time? We’ve tried factory resetting the SPARKs, replacing the RIO, replacing SPARKs, and checking all of our CAN connections, but nothing seems to have resolved the issue. Has anyone seen this behavior from their SPARKs or know how to further troubleshoot it? Thank you!
Here’s a video of the Eboard in action, it fixes itself at 0.38.
This sounds as though it could be a signal integrity problem on your CAN bus. With 14 devices on your bus, you need to have pretty clean wiring. It’s also worth taking a look at CAN bus utilization.
Consider trying a test where you temporarily take several devices off of the bus.
We had the exact same problem this year when wiring up our robot. We eventually found a poor CAN connection that was causing the issue. If you can’t easily find it, one way to test where the issue is is to shorten the bus: at the midpoint of your CAN bus, cut/disconnect it, and then run that one to the termination point. If that solves your problem, the CAN problem was somewhere later in the bus. Add back half of the remaining sparkmaxes and repeat. If that didn’t solve your problem, then it was in the first half. Remove half of your remaining SparkMax’s and repeat. Continue halving the bus until you find it, and you’ll have found your issue in O(log SparkMax) time!
It should be possible to find such a problem by taking the time to meticulously follow each wire through the system, checking every individual connection (not pairs of connections) and doing a pull test. It’s a good idea to have two of your most meticulous team members to serve as QC Inspectors to check for stuff like this. Train your electrical team members to do a pull test after making each and every connection. If they know someone will be checking their work after, hopefully, they will be more careful so and aim to leave no errors for the QC Inspectors to find.
Thank you all for looking into our issue! We were able to solve the problem through a variety of actions. We removed our pigeon and tied up some connections. Our programmers then burnFlash()-ed all of our SPARKs in the code. Then, we re-added the pigeon with neater connections. That order of action seemed to clear everything up!