This year, our team decided to go with TimedRobot instead of IterativeRobot because IterativeRobot is now deprecated. Because of this, we are getting many loop overruns with our swerve drive code.
For each swerve module each loop, we have 4 different calls to different methods (drive.getSelectedSensorPosition(), steer.getSelectedSensorPosition(), steer.set(…), drive.set(…)) where steer and drive are TalonSRX’s. Each of those methods take about .5 ms to 3 ms to call. With each being on average 1.25 ms. This means that 1.25 * 4 methods * 4 swerve modules = 20.
20 ms is already up to the default loop time (.02 seconds) and as we add more talons, the loop time will go up even more. Is anyone else experiencing (or experienced in past years) a problem like this? Is this something to worry about? Will making the loop time .1 seconds decrease the responsiveness of the robot? What’s the best option here?
Also, as a note I measured the times it takes these methods to execute using System.nanoTime().
Check the TalonSRX documentation. As you’ve noticed, some of the API calls take a long time to complete (as they go out to the CAN bus and back), and there are variations that will give you the information you need without taking a long time.
They shouldn’t be that slow, worst case is ~0.4ms, and typically its much better. I suspect something else is going on in your project. Send your project to [email protected] if you don’t figure it out.
I have this all figured out so I figured I’d post an update to anyone else who comes across this.
The TalonSRX#set() methods take little to no time at all. Those were not the problem. The problem was that I was utilizing steer.getSelectedSensorPosition() in my code to update the swerve modules. I needed this because I don’t have the feedback set to continuous and I needed to find the best place to set the position to.
I fixed this by caching the drive and steer sensor positions in a separate thread and getting them whenever I need them. A better way to do this would be to not use those values at all, back I’m not sure how to make it continuous while also only turning a maximum of 90 degrees to get to the desired position and reversing the drive motors (what I call quick reverse).