Concern on NetworkTables reliability

JHS-Viking-Robotics / FRC-2022

Code for the 2022 FRC season, now written in Java

Other

2 stars 2 forks source link

Concern on NetworkTables reliability #30

Closed derickson2402 closed 3 years ago

derickson2402 commented 3 years ago

New features are relying heavily on the NetworkTables server. This is a useful design paradigm for implementing the Shuffleboard and its controls. However, this also introduces a large point of failure. Robotics competitions are not known for their gentle, peaceful atmosphere, and it is always expected that the robot can/will be completely removed from the Driver Station at any given time.

I would like to research and test the reliability of the NetworkTables server. There needs to be some sort of failsafe which will stop the robot, one which does not involve NetworkTables at all.

Possible solutions

Subsystems have member variables for isDisabled or isOverridden
Create a method which toggles the isDisabled
Every method in a subsystem checks that the system is not disabled before it does any action

derickson2402 commented 3 years ago

Several recent commits on feature/hopper-subsystem branch have used the values in Constants.java as defaults within getter methods for NetworkTables values. This means that there should be reasonable safety in the event of network failure.

Things to research about NetworkTables:

How long does it take for values to populate?
How much bandwidth is used? (only 5-10mbps is expected during competitions, if that)
Are values cached? Are these cached values used during network failure? What about once the network is back up?
How are exceptions handled (i.e. value not found, network error)

derickson2402 commented 3 years ago

I am not sure, but I think that the actual driver station uses network tables as a backend.

derickson2402 commented 3 years ago

Is there a way to only have some of these values be accessible during a test mode? Possibly by making a predefined layout on the driver station laptop that does not have the different subsystem tabs?

derickson2402 commented 3 years ago

Resources for learning about NetworkTables protocol:

Key takeaways:

NetworkTables is an independent protocol which WPILib is implementing, and is developed specifically for reliability and ease of use. WPILib implementation also focuses on reliability and resiliency in the face of disconnected clients
The NT server is on the robot itself, the dashboard is a client. So the robot will continue running even if all clients disconnect
NT server is used for FMS info to the robot
Clients are required to optimize their requests (only send latest value, only send value which has changed, etc.), to conserve bandwidth and reduce errors
New data from a client should populate almost instantly after the next packet is sent to the RoboRIO (every 20ms by default, more frequently if desired)

derickson2402 commented 3 years ago

In theory at least, NetworkTables should be perfectly safe to implement. Unless significant reliability, latency, or safety concerns come up in field testing, I think this issue should be closed

derickson2402 commented 3 years ago

As of 443fb05 on feature/hopper-subsystem, there is an issue where the subsystem does not seem to be activating, so control through NT is not working. However, this is more than likely due to buggy code and a general lack of caffeine rather than a problem with NT. If this bug gets resolved quickly, then this issue should be closed.

derickson2402 commented 3 years ago

Fixed the bug with 9becad8 on feature/hopper-subsystem, it was a general lack of caffeine rather than a NT problem. No wireless testing has been conducted yet but over a USB cable it worked perfectly. Closing this issue unless someone finds a problem during more extensive testing.