Enable the robot to interface with NetworkTables and utilize the transmitted values

[maxspier]

Description

PR enables code to get the values from the Orin through networktables and organizes them into apriltags, with the call of a method. The method is static - so it can be called from anywhere.

How Has This Been Tested?

Not tested yet. I'd like to have some feedback on the organization here before the code is tested.

Plane Impact Of PR

PR closes: 164
On approval, PR closes: 187

---

This change is 

[rcahoon]

BTW, this repo is a little out-of-date at this point. Most modern development is happening in Team766/2024

[dejabot]

super cool! there's stuff here that could be useful for reading from NT more generally. happy to chat through comments and thoughts at a meeting too.

[maxspier]

BTW, this repo is a little out-of-date at this point. Most modern development is happening in Team766/2024

Yep. Developing here and then will bring changes to 2024 to test!

[rcahoon]

you might consider writing a unit test for this code. you can have the test code write values into network tables, then call getAllTags, then assert that the returned AprilTags have the expected values

[dejabot]

something to consider (what's more typical, easier to test, less error prone): instead of having this as a "utility class" (class with only static members and methods), make the members and methods non-static, and create an instance of this in GetAprilTagPoseData.

In a unit test, you could have a "fake" implementation of this that provided data from memory etc.

If this isn't making sense, happy to talk thorugh this on chat or f2f.

[maxspier]

Why would we want to have an instance of this class? The design of this class is to be a utility class for the first layer of getting data from NetworkTables to the robot. IMO I don't think it would be good to make it non-static if we are going to want different parts of code using it at the same time.

[dejabot]

you typically do not put this kind of state in utility classes; utility classes are typically stateless:

https://medium.com/@salmankhan_27014/best-practices-for-creating-utility-classes-in-software-development-6f9ad1e8d27a

Having all of this state in static members can make the implementation and the usage harder to read and manage, and it makes the code harder to test.

for the use case you're describing, you can use the "Singleton" design pattern:
https://softwareengineering.stackexchange.com/questions/235527/when-to-use-a-singleton-and-when-to-use-a-static-class
https://www.digitalocean.com/community/tutorials/java-singleton-design-pattern-best-practices-examples

In a Singleton, you have all of the relevant state in an instance, and you only allow creation of a single instance (which you could replace through eg package visible methods) for usage throughout your code.

Does that make sense? Happy to explain/chat more.

[dejabot]

(this is non-blocking ofc :) - more just feedback on what typical industry practices are for coding something like this - and how you can make this code easier to maintain and test.)

[maxspier]

Ah! I'll take a look tonight at the meeting! Thanks!