network tables and the raspberry pi

[MikePerreman]

well, the title is self explanatory, anyone know how to include the network tables, and more importantly, get them to work "properly"

[Jchau]

I am not sure if you have seen this yet: https://github.com/robotpy/pynetwork...master/samples.
It pretty much has everything you need to know to use the network tables on the raspberry pi, from installation to sample code.

[BenBernard]

There are a few threads on the subject here, but if you just want code, please feel free to look at our 2016 pi-tracker in github: https://github.com/frc5687/pi-tracker.

Also included is the networktables jar file.

There's not much documentation on github, but the code itself should be fairly clear. You're also welcome to PM me with questions.

[BenBernard]

I assumed java...but of course if you were looking for python, go with jchau's reply above!

[Jchau]

If you do choose to go with python, you can get more information about installation as well as the API reference here: http://pynetworktables.readthedocs.io/en/latest/.

[MikePerreman]

alright, thanks for the quick info, ill give this a shot!

[RyanN]

Python example: https://github.com/GarnetSquardon490...or_shutdown.py

[bankst]

Here's 832's brand new OpenCV code using python and pynetworktables:

https://github.com/oscarrobotics/VisionOnPi2016

If you're using the Pi for Vision Processing, you can also just copy the whole thing, as long as you follow the instructions in the README

[kmckay]

Originally Posted by BenBernard

There are a few threads on the subject here, but if you just want code, please feel free to look at our 2016 pi-tracker in github: https://github.com/frc5687/pi-tracker.

Also included is the networktables jar file.

There's not much documentation on github, but the code itself should be fairly clear. You're also welcome to PM me with questions.

I see its been updated to eliminate NT and use UDP, did the NT code work? Any landmines that you recall?

[BenBernard]

We encountered substantially more lag with NetworkTables than with straight UDP. Plus, we would occasionally see odd behavior in the NT version that may or may not have been caused by NT bugs. Values would change at unexpected times, etc. I think we were just pushing more data through NT than it was designed for, so rather than debug we switched to UDP and the problems went away.

[kmckay]

Originally Posted by BenBernard

We encountered substantially more lag with NetworkTables than with straight UDP. Plus, we would occasionally see odd behavior in the NT version that may or may not have been caused by NT bugs. Values would change at unexpected times, etc. I think we were just pushing more data through NT than it was designed for, so rather than debug we switched to UDP and the problems went away.

Do you have a good source of code for reading the UDP into a robot program?

[BenBernard]

Originally Posted by kmckay

Do you have a good source of code for reading the UDP into a robot program?

I'll let you judge whether it's "good" or not, but we do have both ends of the UDP communication in our github.

On the pi, we run pi-tracker and communicaton with the rio is through RobotProxy. RobotProxy starts a thread to listen for incoming UDP packets from the rio, and expose the incoming values. It also provides the Send method to send updates to the rio.

On the rio, the robot code uses the PiTrackerProxy exactly the same way: it starts a thread to listen for incoming packets from the pi while providing the collect method to send packets to the pi.

Note that the reason for this complicated mechanism was to more precisely correlate the timing of images to the position the robot was in when the picture was taken. For more on this, see Team 254's video and presentation.

We then compute a new "target" pose based on the image and pose when the image was taken, and use PID to get us there.

[BrianAtlanta]

The biggest drawback to NT, is the update frequency, the fastest you can configure them to update is 100ms. Does that hurt, depends on how you use it. Faster doesn't always mean better. But when you add in the delay of the co-processor to process the image, and include in the NT delay, it can quickly become a problem.

In our code, NT was fine, but UDP would have been better and reduced oscillation during targeting. But with NT we could fire in about 3s (turn and elevate), and hit 80-90%. We will look at UDP in the future, but NT are a good V1.0 option, just understand the limitations.

[Peter Johnson]

Originally Posted by BrianAtlanta

The biggest drawback to NT, is the update frequency, the fastest you can configure them to update is 100ms. Does that hurt, depends on how you use it.

This has been changed for 2017 to allow as fast as 10 ms update rate. https://github.com/wpilibsuite/ntcore/pull/89

[BrianAtlanta]

Cool, glad to see the option for less than 100ms. We'll have to test it out.