GRIP, Network Tables, and mutual exclusion

[RoboPirate]

I've been trying to determine the cause of occasional crashes of our robot code. We are using GRIP running on the RoboRIO and access the network tables in our robot code.

I can't find any method in NetworkTable to ensure that we get a coherent set of information from the camera. We access multiple sub-tables in our target processing (width, height, X, and Y centers). However, there doesn't seem to be any guarantee that each table we fetch is referring to the same image. There is no mutual exclusion for the table so, in theory, GRIP could be updating the table at about the same time we are accessing it, giving us a set of sub-tables that don't go together.

Do the task priorities in RTLinux guarantee that this won't happen or is there some mutex mechanism I haven't found?

[ThomasClark]

NetworkTables guarantees individual reads and writes are atomic, so you should be good there.

It's possible that GRIP is writing, for example, the area array and the centerX array, and one in a while you happen to read both of them after only one has updated. In this case, the arrays could have different lengths, so you could get an error if you use the same loop counter for them.

The solution right now would be to check that the arrays have the same length, although in the future it would be good to support NetworkTables RPCs.

If you're only reading a single snapshot, you can also set "GRIP/run" to false and wait a little bit before reading anything.