In one of his videos about CAN,https://www.youtube.com/watch?v=fiwsPt0FBy0 the gentleman from Playing with Fusion makes an ominous comment about using 15 motors potentially causing issues, but did not seem to specify what that was. I know teams use more than 15, so I’m trying to figure out if I just misunderstood or whether there is a potential problem, and something to prevent it other than following the usual CAN bus rules. Thank you.
1 Like
Yes, the can bus has a limited bandwidth. We typically use a CTRE carnivore for our drive train motors and then put all of our tooling motors on the normal Rio can bus.
We run 18 to 20 motors on our robot.
1 Like
The FRC CAN Device Spec can support up to 64 of any particular device (i.e. 64 SparkMaxes), multiplied by different device types, manufacturer IDs, etc… I didn’t count the bits, but it’s rather large.
That said, theres a practical limit as well, as there’s only so much available time on the wire. But this will depend how “chatty” the devices are.
1 Like
The point he is making is to acknowledge that the CAN Bus has a finite amount of throughput.
While type of CAN device varies greatly in general most vendors seem to enable lots of CAN info by default. In practice you will find somewhere around 15 is where you will fill up the bus with these default settings and will have to start modifying the default StatusFrames. If you do that you can fit many more motors.
1 Like
THanks
Running Rio, PDH, 17 spark max and 2 spark flex on our RIO bus with default setting yielded 95% utilization. With the smallest amount of tweaking it sitting at 75% which we are happy with.
1 Like
Is there somewhere to find more information on how to limit what the devices are using/requesting?
Also, if the motors or devices are not being used (like a sensor or a climbing motor), can I assume they are not using CAN bandwidth? Or do they like to chat even when they are on break?
Thank you.
Can you describe or point to some references on the tweaking you did?
For CAN Spark Max: Control Interfaces - SPARK MAX
We dont care at all about analog sensors, so we set those to their max. On motors like our intake we are not doing any feedback so the position frame was set to max.
We went though each status frame, decided if for that motor we needed the data updated that fast (if at all) and set them.
Reminder: for REVLib, can status frame timings are reset on power cycles so you need to set them on each boot.
2 Likes
I need help on this as well. We have 3 SparkMax controllers and 13 Falcons. Our bus percentage, as shown on the driver station, get’s to about 80 percent, but also shows TX Full errors and we get CAN errors from the SparkMax controllers, and our all-Falcon swerve drive stutters often. We were logging speed, position and voltage for every motor, but we shut all of that off thinking that would help and it didn’t seem to make a difference.
Reading through the CTRE documentation, it seems that making repeated calls to get_velocity or get_position is just using the cached data and not actually causing extra traffic on the CAN bus. I haven’t looked into how the REV devices work yet.
So I’m down to trying to optimize further, but one big piece of information I don’t have for the Falcons is what signals are in which status frame.
I was thinking I could shut off the position signals of the flywheels, but if the position signal and velocity signal are in the same frame, then they get sent at the highest frequency. But, if I’m just using closed-loop control with MotionMagicVelocityVoltage, can I just set the get_velocity signal to a lower frequency (and all the other signals in that frame) since it’s all closed-loop control?
Then there is control signal frequency and I don’t understand that at all. I thought that the controls were sent every 20ms if we are commanding changes every loop of the code.
What am I missing? Are the signals and their status frames documented somewhere? What are you all doing to optimize the CAN bus for your swerve drives and other motors?
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.