These seem to roughly align if you ask me, based on a very similar configuration on our shooter wheel in 2020.
That being said, keep in mind… 50ms is 2.5 control loops on the RIO. While that’s not completely trivial, it’s also quite small - in the region where things like CAN bus delay, code order of operations, how you extract out and analyze the desired/actual speed timeseries signals… all this can start to stack up.
All that being said -
A couple concrete scenarios that fit this description:
- RIO has unexpected delay between executing a line of code, and sending a CAN bus message
- SparkMax has unexpected delay between receiving a CAN bus message and changing the motor output voltage
- SparkMax has unexpected delay between a change in mechanism motion, and reading it with some sensor (internal encoder? external encoder? limit switch?)
- SparkMax has unexpected delay between reading a change in the world in a sensor, and transmitting a corresponding CAN bus message
- RIO has unexpected delay between getting a CAN bus message, and changing the value in your software which you are reading
I’m not sure if all of these apply. Not all are easy to measure… for example, using something like the REV hardware client will take certain delays out of the loop, but add new ones.
The key though is that the correct “knobs” to adjust depend on which delay you’re attempting to attack.
For example, 1 and 5 are both dependent on the underlying hardware/software in the RIO which reads CAN bus electrical signals and queues messages back and forth in software. FWIW I doubt the issue is here, given others haven’t found major issues, but that’s not to discard the possibility you’ve uncovered something new.
Nuttle’s advice applies a lot to 3, but assumes external encoder (internal encoder has no corresponding knobs and, indeed, has a non-trivial amount of filtering on it).