High Can Bus utilization

Currently, 14 Sparkmaxes on 14 motors. No other faults. The 2 NEOs on Shooters are running at the same rotation and setting. the 2 NEO 550s on for Intake are also running the same (one follower).

Tripled checked the wiring. Table below indicates the increase/decrease utilization when CAN connection is reduced.
Capture

What can I do to lower this threshold to acceptable number?

Reducing each status frame? Control Signal Frequency?

Reducing PID values?

Thanks

Reducing the status frames of things you don’t care about is probably a good first step. For instance, we set a higher interval for position status frames for motors that operated purely on velocity control, and vice versa. Your probably don’t care about the velocity of your swerve steer motors.

I think you can also set the control frame intervals but I think I don’t think you need to and it’s not super documented from what I can tell what it precisely does.

Also, avoid setting unnecessary things periodically if you are, like for instance pid constants or really anything that’s not a setpoint or duty cycle.

2 Likes

Is this done thru the code or can it be done thru REV hardware client when setting up the SparkMaxes?
Thanks

Either works.

Don’t forget that the through bore encoders are probably used instead of the neo 550’s.

Which parameter in this list represents the status frame?

Thanks

None of them.

im not sure where this code comes from but i had this on an old commit on our repo, feel free to take a look

Either works, but do it in code. Then when you swap a spark max you won’t get in trouble.

2 Likes

FWIW, we set the intervals of all the messages we really don’t care about to large (relatively) prime numbers. If you just set them all to X, then every X ticks you get a burst of them. This really lowered our bus utilization. For next robot we bought a CANivore (I think that’s the name) that lets us have 2 separate CAN busses.

1 Like

Actually, i just took a further look and SPARK MAX Control Interfaces | REV ION Brushless states:

This rate can be changed manually in code, but unlike other parameters, this setting does not persist through a power cycle.

So, I think you need to set them in code. I’d go as far as refraining from making any status frames more frequent than normal in the case of a power loss event or similar so you’re not relying on the faster frame timing (some of my most annoying issues with revlib were re: it’s handling of missing status frames iirc).

1 Like

Thank you!

We got it down to about 65% ish. A big one was what you suggested from swerve steer motors. We also tried big prime number. These seems to do the trick. Thanks again.

1 Like