Hey all! We are using java, and using a WPILIBj timer to measure the duration of execution for our drivetrain code, which uses four SRX’s.
We are seeing about double the execution time while running the field than when we are tethered in the pit. Has anyone else seen this sort of behavior?
Which robot base class are you using - IterativeRobot or TimedRobot? The IterativeRobot class updates the loop whenever joystick data is received from the driver station, so at an event due to latency on the field you could see reduced performance. TimedRobot is a drop in replacement for IterativeRobot.
If you’re already using TimedRobot, I have no idea.
Sadly, timed robot…
What kind of execution time are you seeing? Perhaps you can measure it with a bit more granularity? Eg… doing X takes this long, doing X1 takes this long… etc. Using wpilib.Watchdog.addEpochs can make this easier to measure.
Yeah, we are going to start doing it more granualr tomorrow. We were profiling each subsystem and noticed a similar increase in time in all of them, though drivetrain was the most noticeable. The subsystems that did CAN communication seem to be the biggest hitters…
Further investigation seems quite strange. It’s intermittent now, sometimes we are seeing 25ms execution time, sometimes 2ms. It seems fairly evenly distributed- about half the time is reading inputs from the SRX’s, about half is sending the output, the remainder is peanuts…
Hopefully not related, but we are also started seeing 70-80% packet loss while tethered in our pit over Ethernet sometimes, but never over USB or on the field… Gonna swap that cable tomorrow to confirm, but seems really weird for a cable to go only partially bad like that suddenly and sporadically…
My guess is that you’re having the weird, almost untraceable problem that everyone else is having with overruns. There’s a whole thread on that.
My guess to why it’s your drivetrain is because that’s probably the piece of code that takes up the most time, then I’m guessing whatever is causing everyone overruns is more likely to be scheduled to be run while methods that go out to the CANBus block the main thread. That’s a guess, but really if you look at the other thread, people don’t really know why that’s happening.
As for it only happening depending on being on the field or through ethernet, that sure is weird. I don’t think it’s anything you’re doing wrong, so you’ll probably just have to wait for a fix, or what for someone to tell you that you’re doing something wrong.
Other thread: TimedRobot loop overruns and inconsistent loop timing (Java)
CTRE just released a blog post discussing this issue, it’s well worth reading.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.