Transmitting data to the cRIO from the Driver's station via TCP/UDP
 

In some other threads, I noticed programmers talking about sending data to the cRIO directly over TCP/UDP ports. Was this competition-legal? If so, what ports were accessible to us?

Re: Transmitting data to the cRIO from the Driver's station via TCP/UDP
 

More information was given about the open TCP/UDP ports available for use in Team Update 5 (section 2.2.8)

We successfully got communication between robot and driverstation using these ports to work in LabVIEW, so if you need a hand with that, let me know and I'll dig it up.

Re: Transmitting data to the cRIO from the Driver's station via TCP/UDP
 

Thanks for the link! And indeed, if you have any sample code, I would definitely like to see it - out team is experimenting with this sort of thing in the offseason.

This certainly has the potential to be very useful - in the past, we've used the DS front panel as a way to get a lot of debugging information about the live robot, but this means we also have the capacity to send a wide variety of command/control signals without having to pipe it through USB or Analog/Digital pins =]

Re: Transmitting data to the cRIO from the Driver's station via TCP/UDP
 

No problem. Attached are two VIs, one for sending UDP packets, and one for receiving UDP packets. They show the basic concept of sending/receiving UDP packets (can also be substituted for TCP packets, the theory is the same - just substitute TCP VIs for UDP VIs). The network communication VIs can be found in the Data Communication -> Protocols -> UDP or TCP palate.

Now, there are two main ways you can do this. First you can "piggyback" off of the regular packets going between the robot and DS. To do that, in your robot code, open "Build Dashboard Data.vi" (in Team Code folder) and you can modify that cluster with your custom data (also make sure the "Dashboard Datatype.ctl" typedef is updated as well, you'll need that later). Then, in a custom dashboard project, update the big constant on the left side of the loop with the Dashboard Datatype (you can just copy&paste), and you can get your data there, after unflattening it from a string.

However, if you want to send data from the dashboard to the robot, the above method won't work very well. You have to use something related to the code I attached. In "Dashboard Main.vi" open up your connection outside the loop and read or write from it on the inside (you will want to put a pretty small timeout on that, maybe 50ms. This will keep your code executing quickly). Then, on the robot side, you can open a connection on the same port (make sure it's one of the ones open on the field) and do the opposite (read or write) of the dashboard.

Also, I should throw in an obligatory warning: do not use this to circumnavigate the standard way of driving robots (i.e. driverstation -> FMS -> robot). By this, I mean: only use this to send auxiliary data between the driverstation and robot. Do NOT attempt to try and get around the usual means of communication, only supplement them.

As always, if you have any questions or if I missed something, let me know, and I'll be glad to help.

Re: Transmitting data to the cRIO from the Driver's station via TCP/UDP
 

Hi I keep getting an error
"Error 56 occurred at UDP Read in Receiver.vi->Dashboard Main.vi"

The errors are coming from this subVI that you have provided. Do you know if the ports have changed in the new 2012 LabVIEW or if there is another incompatibility?

Thank You for your help in advance

Re: Transmitting data to the cRIO from the Driver's station via TCP/UDP
 

Error 56 means that your code has timed out (i.e. the network hasn't given LabVIEW a response in an appropriate amount of time). Since the error is coming from the Read VI, that means that your code is waiting for a packet to be sent, but one isn't being sent. That makes your code time out.

Since that example wasn't really intended to be used on a robot, I did not specify a Timeout value (see the UDP Read Docs), as the example was really only to demonstrate syntax. Now, that doesn't mean you can't use it on your robot, you'll just have to tweak a few things to get it to run in real time.

First, where in the code structure are you putting this VI (since you said the error happened in Read.vi, I'm assuming this is in the robot part of the code)? It should probably go in Timed Tasks.vi. There, you can make a while loop only for your UDP communication and put a relatively slow delay on it (~100 ms?). Then, you should put timeout values on your network VIs. The value is in milliseconds, so a value around 100 is probably good (this depends on how fast your loop runs).

If this code is on the driver station, then I'd just recommend using the dashboard communication that is already taking place to send data from robot->DS; it'l be much easier to work with (see my last post). But, if you're sending data from dashboard->robot, then this is one of the better options.

If you keep getting errors, you can always unbundle the error out cluster and check if it's a timeout error (the code part of the cluster is 56) and clear that specific error. I can elaborate on that more, if you need.

i have not checked the latest cRIO image but last years version had a problem with an unchecked buffer. the tcpip would crash the communications with the robot if to many directed packets arrived at the robot but were not retrieved from the buffer. To avoid this, make sure that the robot code us running before you start sending data to it, and limit you traffic to the robot. I used this method to control the robot via an Android and IOS devices in the off season.

Re: Transmitting data to the cRIO from the Driver's station via TCP/UDP
 

Would it be legal to do vision processing in the Dashboard and sending the results to the cRIO? If so it seems like the easiest solution. The Dashboard already receives a camera image, and its computation power is hardly used while driving the robot. I'm just not sure about the rules (couldn't see any that disallow it but may have missed it or didn't look well enough).

Just for convenience, here's the port list from this year's manual:



So yeah, questions:
1. Is port 1130 used in the default code? Is it used in any optional SubVIs that make things easier? (I don't really need it to be easier)
2. Would it be legal to do vision processing in the Dashboard and sending the results to the cRIO? (If it's legal, is it legal during Autonomous/Hybrid as well?)

Re: Transmitting data to the cRIO from the Driver's station via TCP/UDP
 

We're trying something similar to the OP here: We want to have the Dashboard sent to the robot using UDP. We're simply opening a socket on UDP port 1130, using the Flatten to String function to turn the image into a string for transmission, then sending to the cRIO w/ the UDP Read function. However, we're getting the following error:

We haven't actually set any sort of buffer, so this is sort of confusing. If the datagram is actually too large to be sent, then we'd need some way to compress the data.

EDIT: Turns out the Clear Simple Errors VI was missing. This issue's cleared up.

Now, though, the data doesn't seem to be getting to the cRIO. We're reading the UDP socket from the Periodic Tasks VI, and the Emptry String function is reading True, which says to me that there isn't any information coming through the UDP connection.

Re: Transmitting data to the cRIO from the Driver's station via TCP/UDP
 

The buffers are there. Look at the input to UDP Read; you can set a number of bytes to read. If you're getting this error, why can't you just send all your data using more than one packet? You can split up all your information and send different parts of it on different iterations (this is actually how the robot sends large amounts of data to the dashboard).

Re: Transmitting data to the cRIO from the Driver's station via TCP/UDP
 

See the edit.

Re: Transmitting data to the cRIO from the Driver's station via TCP/UDP
 

UDP is a very basic communications protocol, quite good for sending small amounts of data in a repeating fashion. If you find yourself with more data than will fit in UDP ( about 1500 bytes is typical ), I'd suggest using TCP.

TCP will automatically break a big packet into smaller ones, and reassemble on the read end. It ignores duplicates, checks for missing elements and corrupted elements, and puts sub packets back in order if they happen to arrive out of order. There are other difference too, but the camera and other HTTP sessions are based on TCP.

The error you received was indicating that the buffer was bigger than the UDP limit. When the issue looked cleared up, it was just that you were discarding the error.

As I pointed out in the other thread, there is no reason to send an image. The dashboard already displays it. Why send it again?

Greg McKaskle

Re: Transmitting data to the cRIO from the Driver's station via TCP/UDP
 

How big is the UDP buffer? Because all that I'm sending is the Target Info array from the vision code flattened to a string...

Re: Transmitting data to the cRIO from the Driver's station via TCP/UDP
 

I believe the UDP limit is somewhat dependent on the devices being used, but in this instance, I think 1500 bytes or so.

Greg McKaskle

Re: Transmitting data to the cRIO from the Driver's station via TCP/UDP
 

The TCP code in the screenshot is giving me the following error:

I can only assume this means it's timing out, but why would it do that? It seems as if all of the parts are in the right place.