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

[plnyyanks]

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

Originally Posted by Team Update 5

Once plugged in to the Field Management System via the Ethernet cable provided, the ports that the
teams will be able to access on the playing field are as follows:
– TCP 1180: This port is typically used for camera data from the cRIO to the DS when the
camera is connected to port 2 on the cRIO. This port is bidirectional on the field.
– UDP 1130: Dashboard-to-Robot control data, directional
– UDP 1140: Robot-to-Dashboard status data, directional
– HTTP 80: Camera connected via switch on the robot, bidirectional
– HTTP 443: Camera connected via switch on the robot, bidirectional
January 25, 2011All these ports are open on the playing field, so a team can use them as they wish if they do not
employ them as outlined above (i.e. TCP 1180 can be used to pass data back and forth between the
robot and the DS if the team chooses not to use the camera on port 2).

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.

[JohnGilb]

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 =]

[plnyyanks]

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.

[Philipose]

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

[plnyyanks]

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.