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

[JohnGilb]

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?

[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.

[SuperS_5]

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.

[NeatNit]

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:

Originally Posted by the manual as of 29.1.12

2.2.9 The Player Stations
One Player Station is located between the Inbound Station and Corral. The remaining two Player Stations are located on the opposite side of the Corral. The Player Station on the end of the Alliance Wall is 51 in. wide, while the other two Player Stations are 72 in. wide. All three Player Stations have the components detailed below.

Attached to the Alliance Wall in each Player Station is an aluminum shelf to support the Operator Consoles for the FRC team in that Player Station. The support shelf measures at least 48 in. wide by 12 in. deep. There is a 3 ft long by 2 in. wide strip of Velcro tape (“loop” side) along the center of the support shelf that may be used to secure the Operator Consoles to the shelf. Each setup location includes a competition cable (to provide Ethernet connectivity) that attaches to the Ethernet Port of the Operator Console. The cable provides communications with the Robot.

Each Player Station also includes a power adaptor cable that may be used to power the Classmate laptops that were provided to teams in the Kit of Parts starting in 2010. Emergency Stop (E-Stop) buttons for each Robot are located on the left side of each Player Station shelf. Arena components (including team number displays, competition arena hardware, alliance lights, control hardware cabinets and clock displays) are also located above the Player Stations and below the shelf.

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.
– TCP 1735: SmartDashboard, bidirectional
– 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

All 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).

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?)

[Pirate programe]

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:

Error 113 occurred at UDP Write in Dashboard Main.vi

Possible reason(s):

LabVIEW: A message sent on a datagram socket was larger than the internal message buffer or some other network limit, or the buffer used to receive a datagram was smaller than the datagram itself.

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.

[plnyyanks]

Originally Posted by Pirate programe

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.

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).

[Pirate programe]

See the edit.

[Greg McKaskle]

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

[Pirate programe]

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...

[Greg McKaskle]

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

[Pirate programe]

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

Error 56 in TCP Write in Dashboard Main.Vi

Possible reason(s); The network operation exceeded the user specified or system time limit.

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.