Re: Vision on separate board
 

What FPS did you get?

Re: Vision on separate board
 

The biggest issue I've been having so far is just getting communications up. What's your preferred method of interfacing the board with the cRIO? I've tried a basic TCP, but I was getting a ton of lag for some reason.

Re: Vision on separate board
 

Our approach is to have the offboard processor do all the heavy lifting. It processes the images to determine the "target" location. It then places that information in the form of a string into a memory location. Every image that generates a valid target, over rights the previous data.

We use a Socket Request handler on the board to respond to Socket Requests from the cRio. The response to a Socket Request is to send the latest string to the cRio and then close the socket. This way only the latest target information is passed to the cRio as a 24 character string. The cRio then uses that information to perform whatever task we have coded it to do.

We are not sending images from the board to the cRio. Doing so would really defeat the purpose of using the offboard processor.

Re: Vision on separate board
 

I bet the team was proud of the vision tracking!?:D :cool:

Re: Vision on separate board
 

Pardon me for being a bit dense, but how are the Socket Requests sent? Most of my difficulties have just been getting the Pi and the cRIO to talk to each other, and my efforts with NetworkTables have been met with considerable frustration. Do you guys have any advice?

I also started learning NetworkTables very recently (about 1-2 weeks ago), so my knowledge might not be as thorough as it could be yet. This is pretty much my working knowledge of it.

Re: Vision on separate board
 

Ewww, ich, Network Tables! I have had nothing but headaches learning about them.
This method does not use them.

In the attached picture, you can see what our "Socket Request Receiver" looks like.

We only run it 10 times a second because that is sufficient. Everything other than the TCP Open Connection, TCP Close Connection, TCP Read, and Scan From String are there to display the data or create target center data.

The IP address and Port numbers are set to point to the PCDuino, or rPi in your case. The IP and port combined create a "Socket". The PCDuino listens for requests on that "Socket".

Re: Vision on separate board
 

I contacted RoboRealm and they are coming up with an ARM version for Linux. Sadly, it won't be out till next year. Anyways, how do you guys think about setting up with RoboRealm and using the same commands in OpenCV onboard the robot

Re: Vision on separate board
 

Try UDP, it is faster than TCP!

http://www.diffen.com/difference/TCP_vs_UDP

Look at this, it tells you all the differences between them

Re: Vision on separate board
 

Dat's a pretty good differentiation

Re: Vision on separate board
 

Is it possible to communicate with the cRIO via UDP (target information) and the DriverStation via TCP (sending camera images) at the same time?

Re: Vision on separate board
 

The driver station talks to the robots via UDP and the dashboard uses TCP.

I'd hesitate to simply call UDP faster than TCP. They are like nails and screws, and you should use the right one for the task. If you attempt to make UDP as robust as TCP, you will almost certainly add more overhead than TCP. And if you don't, you will lose data and the rest of your application will need to deal with holes in the data.

UDP is great for repetitive protocols where you can tolerate lost packets. It also limits the amount of data you can send in a single UDP packet. TCP can send large payloads, it checks and retransmits portions that are lost, and gives the recipient the data that you sent, but it will sometimes take a bit longer to do so.

Greg McKaskle

Re: Vision on separate board
 

Well how big is the tracking information? It should just be a string of coords and maybe some other information

How much of that can you send in a packet? I'm not good with networking, but I don't think that would take too much bandwidth for that...

And do you need like 20fps for vision? I can process that no problem, the only thing is, do I need to? Maybe just send vision data when you are aiming. I don't see the point of trying to find targets when you are picking up frisbees

Re: Vision on separate board
 

Yes.

Re: Vision on separate board
 

I will second what Greg says above. Even in the video games industry we almost exclusively use TCP nowdays (though that is not my area of expertise). I'd only use UDP for things where you don't care if you lose a packet and I'd use TCP for everything else. Using UDP to transmit joystick controls or something like that (with a simple mechanism for ignoring "older" packets) makes sense for example.

Our Kinect co-processor in 2012 was a TCP listen server. We used the information on this site to learn enough to write the necessary networking code: http://beej.us/guide/bgnet/ The cRio connected as a client to our pandaboard "server" and you could also connect to the pandaboard from the driver station. We used simple strings for our commands so you could interact with it through a telnet prompt from the driver station. To do this, all you need is the code to open a connection and then send strings back and forth.

Re: Vision on separate board
 

I use UDP all the time to move large specific flows of data within massive server environments (10,000+ systems) with very strict timing requirements.

As others have said TCP works in the general case. It works well for sending data of some unknown type at some unknown interval over a generally reliable link.

Where TCP does not do so well is in situations it was really never designed for. Streaming video in real time. Sending timing sensitive data where the TCP process to insure data transmissions reliably get to the other end might get in the way on unreliable links.

There are often situations where you can engineer one system or the other to tolerate situations where TCP has shortcomings.
There are other situations where it just makes more sense to use UDP.

How much data do I send through UDP every day? 50-75 Gigabytes.

Please be aware if you are using UDP on Linux you really should tune the communications stack parameters to make it more tolerant. The default parameters for UDP will often contribute to UDP packet loss on links that are common place. Of course make sure you consider that FIRST exercises some control on this system so there are some parameters you can't control (like in the field, on the robot communications hardware or within the some peripherals).