Offboard Camera Processing?

[charsmud]

My team is trying different methods of angle and distance detection, and we are trying vision. However, we want to do the camera processing at the station, not on the robot itself. How would we go about offboard camera processing?

[Joe Ross]

Are you having trouble figuring out how to do the camera processing on the driver station computer, or having trouble figuring out how to communicate the results to the robot?

[charsmud]

I am having trouble communicating from the robot to the driver station.

[Joe Ross]

If you're using LabVIEW, SmartDashboard, or RoboRealm to do the vision processing, the easiest way to communicate from the dashboard to the robot would be to use NetworkTables.

[jesusrambo]

Hey,

This was something I spent a lot of time working on last year. We programmed our robot in Java, so what I did was basically open up the Dashboard in Labview, add a VI in it to accept camera input and handle the image processing, and then send back the x,y coordinates of the centers of each detected object to the robot over TCP, which it used in a PID controller that automatically aligned the turret.

I would advise against using NetworkTables, personally. The current implementation is poorly documented, and though it's been changed from the even worse implementation last year, it's still easier and more reliable to just write your own socket code.

[Greg McKaskle]

While there is absolutely nothing wrong with doing your own communication, advising others against using network tables seems a little strong.

Network tables has now been vastly simplified, is based on TCP, and is used for a number of core features in the dashboards. What issues have you seen with it? What documentation did you hope to find?

Greg McKaskle

[RoboRealm]

We would also recommend against using Network tables for the purpose of sending images. That was NOT added to the network tables implementation since it is WAY quicker (i.e. a LOT less data) to send a jpg image over the network using standard HTTP queries. Sending an image uncompressed (or even compressed) using Network Tables is not what it is built for. It is meant for variables and command codes, not images.

If you want to process images on the Driver station get them directly from the Axis camera as .jpg images. That will give you the best bandwidth utilization. Even with that you'll still need to keep things small in order to get frequent images (i.e. 20+fps). If you need to use anything larger it may be best to use onboard computing and avoid the bandwidth throttling.

STeven.
www.roborealm.com

[jesusrambo]

Originally Posted by Greg McKaskle

While there is absolutely nothing wrong with doing your own communication, advising others against using network tables seems a little strong.

Network tables has now been vastly simplified, is based on TCP, and is used for a number of core features in the dashboards. What issues have you seen with it? What documentation did you hope to find?

Greg McKaskle

I'm sure the LabVIEW implementation of networkTables is excellent, but the Java implementation leaves a LOT to be desired.

Let's look in the API, where we find this - 8 separate packages for NetworkTables2 and its component features.

Since there's no example code for Java NetworkTables2, or at least none that's easily findable, trying to figure out the code from the API seems the next logical step. Determining what acts as the client and what should act as the server, i.e. robot or dashboard, is not made any easier by the client API page, which almost completely consists of the class names restated in English instead of any actual descriptions of what they do. As a fun aside, if you look at the methods inside the classes, a good amount of them don't even have any descriptions whatsoever. The server API page is the same.

As I'm said, I'm sure its use in the Dashboard is great, since it's all implemented in LabVIEW. The Java, however, has been all but neglected.

As for what documentation I'd like to see, example code would be nice, followed by actual complete documentation of the classes and methods in the APIs. None of the packages even have descriptions at all, few if any classes have meaningful descriptions, and the methods are the same.

If these issues are resolved, and NetworkTables is developed into a platform that Java programmers can actually easily implement and use, then I will gladly recommend it, as the concept behind it is excellent. Until then, writing one's own socket code is simply easier and more comprehensible.

[Greg McKaskle]

I'm not sure the LV code is excellent, but your feedback on the Java code sounds reasonable. Giving detailed criticism is a pretty big part of learning to analyze code and choose APIs. Perhaps the author will get around to addressing some of your concerns.

Thanks for playing.
Greg McKaskle

[jesusrambo]

Originally Posted by Greg McKaskle

I'm not sure the LV code is excellent, but your feedback on the Java code sounds reasonable. Giving detailed criticism is a pretty big part of learning to analyze code and choose APIs. Perhaps the author will get around to addressing some of your concerns.

Thanks for playing.
Greg McKaskle

Thank you. I hope there is still discussion within WPI on how to improve the Java. Things like, for example, documentation for UDP protocols in the API without actual support in the Squawk VM just show how neglected the Java APIs are. It hugely hinders our productivity, as we have to attempt to implement them before finding out that they're not even supported, and that that isn't documented anywhere. If ChiefDelphi didn't exist, every team would have to discover that for themselves. Not quite optimal.

Thanks again for your replies!

[Joe Ross]

When I started playing with Network Tables, I found that the PID Controller was a helpful example, since there is both a robot implementation and a SmartDashboard widget.