The Watchdog is enabled when the user’s functions start executing and disabled after they finish, so only user code is measured and network packet arrival jitter shouldn’t affect measurement (in other words, IterativeRobot and TimedRobot should behave the same). Try timing parts of the code yourself, or maybe just empty functions, to see where the slowdown is coming from.
Watchdog should have also printed a breakdown of the overrun per-function. What did it say, if anything?
Note that even if you did want to mess with the watchdog settings (which is questionable), you should not be doing it in teleopPeriodic, it should be in a teleopInit function, or in robotInit.
That’s relevant! Missed that. You’re not using arcadeDrive correctly. It expects three arguments: forward/backward, turn, and whether to square the inputs or not. Use stick.getY and stick.getX to do that.
Honestly why do we even have setSafetyEnabled(False)… It is not a fix for broken code. I have never seen anyone use it for something that wasn’t band-aid.
Team Update 14 announced a new RIO image to resolve this:
Control System:A requiredNIUpdate Suite (2019.2.0) with a new roboRIO image (FRC_roboRIO_2019_v14) has been released. This image fixes a bug where robots randomly enter the Watchdog Not Fed state (disabling outputs) for ~2.5s when they should be enabled. To use this image, C++\Java teams must have the previously released 2019.3.2 update installed.