Quote:
Originally Posted by Thad House
NetworkTables should actually be fairly efficient in that use case. All of the data is cached, so reading 50 variables should not take long at all.
There are a few other things to look at however. There are some methods in the WPILib that take 0.2-0.5ms to run, so if you are calling multiples of those they add up quick. One of the biggest culprits of this are the Driver Station mode checks. Calling IsEnabled, IsTeleop, or any of those types of methods do take a lot of time, so if you are calling those in a loop there becomes a lot of lag. Joystick get methods other then axes or buttons also take long to perform. The last ones are CAN calls, which can take a while, especially reads from CAN Talons, which depending on the parameter can take over a millisecond.
|
Imma interject for a minute.
Joystick calls are not slow. They access variables stored in memory that are received from the driver station at regular intervals (around every 20ms for a Driver Station Control Packet). When one of these packets is received, the joystick values are stored in memory, and those are accessed through the Joystick class. There is nothing slow about this at all, in fact, it's probably the fastest way to do something like this. I don't usually applaud WPILib for doing something right, but this is one of those times.
This is true for a majority of WPILib's get functions, as it enables control loops to run quickly without 'blocking' for an external resource. Reading up on the different types of frames used by CAN, The Driver Station and FMS will give you a good idea of why all of these methods are non-blocking.
If you're wondering about your 'taking too long to loop' issue, I'm afraid there's not much help we can provide unless you provide some code. If the loops are taking too long, there are two possible things.
a) The issue is occurring within the loop. Somewhere in the loop, your code is running slowly. This may be an intensive math problem or a function call. If you're using reflection anywhere, that will be your culprit.
b) The issue is occurring outside the loop and bogging down the system. This can be caused by delayed Driver Station / FMS Control Packets (check your wifi router), or by having too many active threads. A good status indicator is your RSL (Robot Signal Light). If it's flashing irregularly, it's an issue outside the loop and your RoboRIO is being bogged down by an intensive process.
If you're running any kind of vision on your RoboRIO, this can also be an issue with the system being bogged down.