We’ve been doing some investigating of the execution time of our main TeleOp loop, and under large amounts of load (swerve calculations + all of our end effectors) we are seeing spikes in the range of 60-120ms. Is this normal? I know that the roboRio runs at 50hz (20ms), but I also know that under serious computational load you are going to see some deviation. What are some standard execution times you guys have seen from your TeleOp Main loop on robots over the years?
That seems pretty excessive - you shouldn’t be overrunning the 20ms per-loop budget. Can you post a link to your code?
We use Labview, so I’m not sure whether you’ll be able to view it or not, but here you go.
Swerve 2.01.zip (503.5 KB)
What types of motor controllers are you using? And how are you connecting those? We had some problems with getting and using encoder values over the can bus.
Swerve drive calculations really don’t take that long to do. It’s probably a problem with something else.
We are using both TalonSRXes and Spark Maxes. We use CAN for all our speed controller communication.
Could it have something to do with the fact that we are running the code tethered over usb and not deploying it? I can’t imagine that that would cause such a huge difference in loop speed though.
We only used CTRE motor controllers and our swerve drive uses 8 Talon SRXs. Do you do PID on the roborio or do you use position control to control your steer modules?
Getting the encoder values over CAN isn’t great, but we have to do that too. Honestly I’m not sure what the best option is here as we need the encoder value, but wish we didn’t have to do it over CAN. I’m debating plugging it directly into the Rio so we don’t have to get encoder values over CAN. It’s also possible that the 2020 CTRE library will be better about getting data over CAN, but we’ll have to see.
We changed the loop time to 55ms, and the only time it went over that was at the start of a new mode, which we don’t worry about. A loop over run every once in a while isn’t bad, but constant over runs are very bad.
We use the built in PID on the Talons.
First, we have to be able to set the position to the correct angle. Ex: 361 degrees instead of 1 degrees. We use the current encoder value to find the nearest angle to set it to.
Second, this year we will be calculating the absolute position by using the angle of the steer module and encoder on the drive module.
Our set up isn’t ideal, and I’m definitely looking for improvements in this.
Do you ever get the encoder position and use its value in the code anywhere? Setting stuff like speed and position to motor controllers doesn’t take hardly any time at all like getting encoder positions sometimes does.
If you don’t get encoder positions in your swerve drive code, I’m not sure what to tell you. If you do, then we’re on the same boat as you are. I probably won’t be able to help you further since I’m not going to attempt to read the labview code.
I think that that is our problem. We are getting encoder values over CAN for each pod during TeleOp, and this appears to be slowing our loop down to around 60-70ms. Not great, but we can deal with it.
One thing to note is for 2020 CAN is exponentially improved, and should not cause issues like this anymore. The whole subsystem has changed, so definitely something to retest once the 2020 image comes out.
1 Like
Thanks for letting us know. It’s going to be really nice to be able to have our loop time down to 20ms.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.