Does anybody know where the specs are for the “user data” sent by the driver station to a generic Dashboard.
There’s docs on how to stuff the data in the robot-to-DS packets but how is this user data sent from the DS to a dashboard; UDP packets on some port to some IP?
There seems to be some docs/examples on the format to send data to the Labview Dashboard but we wish to avoid Labview entirely for the moment and we wish to choose which “user data” we send.
This isn’t a spec, but I can tell you a bit about the data format. For more specifics, the easiest route will be to open the LV dashboard and examine the diagrams for how it decodes things. Sorry, but we wrote the dashboard in LV, and I don’t believe any has been written in C/C++/Java, etc. They certainly can be, the protocol is easy to do in any programming tool, but there is that time thing…
The data is sent back using UDP on port 1165. I’m not certain I have the latest code on the computer I’m looking at, but this code reads 1018 bytes and breaks it into several chunks. The first chunk is described by the first image. This image is what the LV help window shows when you hover over a wire going into the type cast function which takes the first piece and casts and returns the rest of the buffer string for other processing.
The rest of the buffer is decoded as a byte, two strings, and a byte array. The byte is simply used to recognize duplicates and skips, the strings are error strings and user strings. The byte array is true custom user data.
The first structure is further ripped apart, manipulated, and scaled for better presentation.
As for the data packing, the data is sent in network byte order, or big endian, with no spacing between any bytes. The I8 or U8 is one byte, I16 and U16 are two bytes, etc. A string is a counted string, not null terminated. The count is four bytes. The dimension sizes for arrays is the same four byte count of elements. There is more documentation for this in the LV manuals describing the LV binary format. Or of course you can ask detailed questions here.
Greg McKaskle
Thanks. Using your information and looking through the code I think I now have the complete picture.
The Robot sends packets to the DS that may include up to 984 bytes of “user status”. For the Labview dashboard, the “user status” is formatted into a one byte header and three byte arrays, each preceeded by a 4 byte size. The first byte array is printf strings, the second is error strings, and the third is structured data.
When the DS receives a packet from the robot, it formats a UDP packet and sends it to 10.xx.yy.6 on port 1165. The UDP packet contains a 28 byte header as described in Greg’s attachment followed by the 984 user status bytes. These can be received and processed by an application, either the standard Labview Dashboard or any other application that can read UDP packets.
The 28 byte header information is fixed and always present. The user status data may or not be present depending on what’s running in the cRIO.
I seem to be missing 6 bytes somewhere (if 1018 is the total and 984 is the correct user status size) but I suspect they’ll show up when I start looking at real data.
My understanding is that we can either use the Labview format data with a Labview Dashboard, the Labview format data with a custom Dashboard (in Labview or otherwise), or whatever we want to stick into the user status data for use by whatever laptop application we desire.
Does anyone know the packet rate for the Robot to DS and/or DS to Dashboard streams?
Thanks Greg for your help.
The data rate should be somewhere around 50Hz.
Except for the first 28 bytes, I think you can change anything you want as long as you change both sides. The rest of this was really just a suggested example usage. I suppose the C/C++ side could expose it differently, but I suspect it is again, just an example usage.
Greg McKaskle
If anyone can comment on whether the following is OK, it would set our minds at ease. Our dashboard works well in our home setup, but I’m paranoid that something will go wrong trying to use it with the official FMS:
Instead of using “user data” we followed the instructions in the “build dashboard data.vi” that comes with the basic labview framework. It tells you to modify the dashboard datatype.ctl typedef for the data you want to send, and be sure to pick up the mod in your dashboard program too.
We did this, and it’s a very simple way to customize your dashboard, and works great. I would recommend it as more powerful than the user data mechanism. I’m not sure why this hasn’t been mentioned in these posts.
But then, I’ve seen all these posts about the FMS having it’s own ideas on what data to pass along, notably a video channel that can be shut off. Is our dashboard datatype going to work the same way with the FMS? We’re not sending a lot of extra data, maybe 40 bytes or so, but it would be a nuisance to have it cut off or something. Thanks for any insight on this!
Yep. Everything except for the video is just part of the 984 user bytes, and the FMS will dutifully pass it from robot to your DS to your dashboard program.
Greg McKaskle
i heard that there is a limit on how big your packets are when sending them to and from the robot. Can anyone tell me if this is so and if so, what is the limit?
You can send 984 user bytes in each packet and 50 packets per second.
If you plan to send larger objects that span multiple packets, you need to take care to protect from loss, duplication, and out of sequence delivery.
Under most circumstances your packets will get through as sent but you don’t want to crash your program if one of the relatively rare conditions occur.
Remember, Murphy is at every match.