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?
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.
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 =]
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.
UDP Send.vi (6.86 KB)
UDP Receive.vi (6.67 KB)
UDP Send.vi (6.86 KB)
UDP Receive.vi (6.67 KB)
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
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.
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:
- 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)
- 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?)
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.
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).
See the edit.
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
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…
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
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.
This thread has been quite helpful. I am still somewhat stuck with an issue on the cRIO crashing when I send UDP to it. I suspect it has something to do with the buffers, but if anyone has helpful advice, I’m open to it!
NetworkcRIO.zip (52 KB)
Screenshots.zip (57 KB)
2012 Dashboard ProjectVisionProcessor.zip (315 KB)
NetworkcRIO.zip (52 KB)
Screenshots.zip (57 KB)
2012 Dashboard ProjectVisionProcessor.zip (315 KB)
A couple of TCP and UDP tips and comments:
-A UDP packet is designed to fit in one Ethernet frame, limiting it to 1500bytes minus UDP headers. I believe a UDP header is 8 bytes, but don’t quote me on that
-TCP is designed to send streams of bytes instead of packetized data. The disadvantage to this is that the sending application must explicitly manage the send buffer and force TCP to send it all of the bytes, and the receiving application must manage packet starts/ends.
-TCP is also a reliable medium, with error checking and retransmission. This is usually a bad thing if you care more about getting the data fast than getting all of it (if you miss a targeting packet, you will get another one in about 50ms, so you just ignore it).
-UDP is a better choice for this application due to the speed and packet-oriented nature.
-The UDP listener should have errors trapped and a timeout set to a fairly low number (I use 1000ms) - I use trapped errors as a source of determining if I actually should unbundle the packet and use it
-The UDP listener should exist in its own thread (While loop) throttled by nothing other than itself - There should be no waits. The UDP listener will block for new packets, and if you are behind in receiving packets then it’s a bad thing.
-Send the smallest packets possible - Do all target filtering and multiple target analysis (stuff that works with arrays of targets) on the laptop, and send a single target coordinate to the robot over UDP - This keeps the packet size under the limit and non-variable.
I didn’t run your code yet, but looking at the screenshots, it does look like you are only reading the udp data five times a second, pretty slow. But you shouldn’t crash the cRIO doing that. What sort of crash is it?
Greg McKaskle
When you say crash - exactly what happens? If you can reproduce a crash with a simplified program, please contact National Instruments via our FRC forum. We can have application engineers look into it.
CD,
Man, most of this stuff is over my head. Is there a simple example somewhere to show how to display a PWM channel, Joystick Input, or global variable on the Dashboard?