Determinism and low jitter is especially important for aggressive feedback control.
It would take me too long to dig up hard data, but I can offer some rules of thumb as a team who goes hard on the last 1% of controls performance. We use C++, TimedRobot’s AddPeriodic() for synchronous controller scheduling, and RT thread priorities to improve scheduling jitter (think on the order of ±0.1ms for a 5ms loop).
Here’s example code: Robot-2020/Robot.cpp at main · frc3512/Robot-2020 · GitHub
Fast-accelerating stuff like flywheels
You want 200Hz sample rate and minimal measurement latency. Latencies beyond 20ms are untenable because it oscillates too much. That means doing roboRIO controllers with CAN encoders won’t work because the status frames are nondeterministic, and can have up to 20ms of lag (any faster saturates the bus).
Motor controller PID works as long as you don’t use the default filtering options. They can introduce between 10ms and 20ms of group delay. For SPARK MAX, I recommend the “alternate encoder” support because you can reduce the amount of filtering (you can’t for the built-in encoder).
Drivetrains, elevators, etc.
Consistent periods improves odometry accuracy and Encoder class velocity measurements, but not by much at these speed regimes. Having a good drivetrain to begin with is more important.
Don’t do network I/O on the controller thread; it’ll drastically affect your scheduling (±0.5ms or so of extra jitter). Push to a thread-safe queue and do the logging on a separate, lower priority thread instead. It’s less of a big deal for CSV logging, but we noticed small improvements from moving that over too.