I was told there is a way to increase the rate at which the Rio calls TeleopPeriodic or AutoPeriodic for that matter. It defaults to 20ms per each loop but I have been unable to find any documentation on how this it is done. I’ve seen it referenced a lot in many documentations.
I intend for this to help the Rio read off our Camera Tracking values and change accordingly to the incoming values at a faster rate.
Edit: Other people pointed out below this is not necessarily true in WPILib 2018 (which I haven’t touched), though this is still true if you’re looking to use an IterativeRobot base.
I don’t think so. That ~20ms is in line with a ~50Hz polling to DS packets. The source code also supports this claim; periodic functions are called while logic for periodics are performed, and
HAL_ObserveUserProgram<Mode>
is called. HAL is notoriously undocumented, and the implementation of that function in WPILib is a single undocumented NI library call (
FRC_NetworkCommunication_observeUserProgram<Mode>();
), but I’d assume that the function is waiting for a DS packet, or something to that extent. It certainty doesn’t look to have any parameters we can modify.
There is a new 2018 feature that should supply what you are asking in 2018 WPILib. I believe you should take a look at the TimedRobot class in WPILib. It promises to allow the time which periodic tasks are called to a specified value.
https://wpilib.screenstepslive.com/s/currentCS/m/beta/l/801080-new-for-2018
If that is not a solution, Depending on what you are trying to accomplish, writing your own thread that you kick off from one of the other init functions, and controlling the loop rate of the tread will do the job just fine and thats how most teams have gotten by for years.
Hope this helps,
Kevin
In the 2018 WPILib there will be a TimedRobot base that runs at a constant rate, faster or slower than the current as you would like it. Currently the frequency is not exactly 50Hz, but is different based on how often the robot gets packets.
Out of curiosity:
I don’t think there’s a 20ms delay between calls. Here is data that I’ve collected from our robot (Java, IterativeRobot). This is with a 5ms Timer.delay call at the end of TeleopPeriodic. Units are in nanoseconds.
That being said, I do think the PWM update is at 50Hz.
The PWM update rate depends on the target. The base rate is a 5.05 ms loop. This can be divided by 2 or 4 (implemented by skipping the other pulses in the FPGA) for different controllers. VictorSPs, Talons run at the full rate. Old victors and servos run at the slow rate.
We do all our own timing using pthreads/std::thread. I’m not sure you want to go down that route.
