CAN Bus Utilization

CAN 总线都有一定的带宽限制，如果 CAN 的占用率太高会导致机器上的种种问题。过多的 CAN 设备、数据刷新率太高都可能导致 CAN utilization 过高。Driverstation 上可以查看当前的利用率：

DS 上的显示数据可能会频繁跳动导致难以识别具体的利用率，见 WPILib 官方文档这一帖：

CAN bus utilization is noisy

Issue: CAN bus utilization as reported live by the DS or as shown in the DS log has significant variation or “spikes” in the data. This is due to the RoboRIO occasionally counting CAN packets in the incorrect time period, so one period will have a much lower utilization than reality and the next a much higher utilization than reality.

Workaround: Zoom in on the DS log plot and look for time periods when the utilization is stable (the spikes will be both above and below this average). The average utilization is the true utilization.

解决方案参考

• 参考https://www.chiefdelphi.com/t/canbus-utilization-cancoders-can-frame-not-received-too-stale/402791

• 将 PID 控制转为 on-board

• 将不必要的 CAN 设备转为 PWM（如只需 open-looped control 的设备）

• 参考 254 的 LazyTalonFX

不确定是否有效，见 WPILib 开发者的回复：

Doing that doesn’t help anyway. Because the CAN Heartbeats for all the existing motor controllers are sent as part of the control packets, the control packets have to be repeated over the bus anyway. So the control packets are going to go out anyway.

Note this could have changed in recent years, and also could change in future years, but based on the last time I looked at the control encryption this was how they all worked.

• 改变 CAN 设备的 status frame rate

  • CTRE 的设备使用 setStatusFramePeriod() 具体配置哪一项/如何配置 见 https://docs.ctre-phoenix.com/en/stable/ch18_CommonAPI.html

  • REV 的设备用 setPeriodicFramePeriod() 具体配置哪一项/如何配置 见 https://docs.revrobotics.com/sparkmax/operating-modes/control-interfaces#periodic-status-frames

• 参考该笔记

• https://www.chiefdelphi.com/t/does-the-rev-pdh-have-adjustable-periodic-status-frames/404895/15

Couple of other points on improving can bus util (for CTRE devices):

• When setting status frame periods make sure you check the error code and try again if it’s non-zero. Your bus util with that selection of devices will be at or over 100% on boot so you may see timeouts in Begin.vi and need to try again until they succeed.

• Double-check you’re only calling config* routines once or on trigger and not accidentally calling them in a loop - they generate extra CAN traffic.

• As Thad mentioned, calling Set does not generate CAN traffic. HOWEVER, you can change the send period of the control frame as well as the status frame. By default this is 10ms so you can save quite a bit of bandwidth here. As long as you’re comfortable with the response time of your mechanism you’re probably OK changing this to 20ms on most controllers, and on followers you could set it as high as 50ms and likely be safe. Note the controller will timeout and disable if the control data hasn’t been received in over 100ms so I recommend 50ms as the absolute maximum for control frame periods.