Can you programically retrieve match number?

[MasterEric]

Put this under general programming since this is somewhat of a platform-independent question, but I specifically use LabVIEW.

I was looking through the methods to retrieve information from the Driver Station, and found some cool ones to retrieve connection status, robot status, even alliance position and color (Blue 3, Red 2 etc.). These are extremely useful for the purpose of logging, knowing whether you are connected to the field, knowing which log is which, and so on.

My question is whether the current match number can be retrieved as well. I did not find a VI for it, and I couldn't open up the alliance position VIs to see how they worked (they just run a method in a DLL file somewhere). However, match number is broadcast to driver stations, as shown by this documentation page (scroll down to "Identifying Logs from Matches").

I'd love to know if anyone's done this before or can help me find a solution or workaround.

[virtuald]

My understanding is that information isn't available to the robot. The DS knows it (it shows up in the DS logs), so in theory you might be able to hack something together to figure it out... but that sounds like a lot more effort than its worth.

[Greg McKaskle]

The DS sends a bunch of info the the dashboard. I don't think SD currently decodes it and makes it available, but the LV dashboard, top loop, makes a call to Retrieve Status Info. That VI has an output called Power and Errors. Kind of an odd combo, but anyway, in the same cluster is match info. I have never actually tested it at an event, but I suspect that the data will be in there. You could write it to your own file on the DB computer, or you can put it into Network Tables and give it to the robot.

Greg McKaskle

[marshall]

Originally Posted by Greg McKaskle

The DS sends a bunch of info the the dashboard. I don't think SD currently decodes it and makes it available, but the LV dashboard, top loop, makes a call to Retrieve Status Info. That VI has an output called Power and Errors. Kind of an odd combo, but anyway, in the same cluster is match info. I have never actually tested it at an event, but I suspect that the data will be in there. You could write it to your own file on the DB computer, or you can put it into Network Tables and give it to the robot.

Greg McKaskle

Thank you for this! This really needs to be fully documented. I think we are using some of it now but I believe it isn't fully documented about how to do it.

[MasterEric]

Originally Posted by Greg McKaskle

The DS sends a bunch of info the the dashboard. I don't think SD currently decodes it and makes it available, but the LV dashboard, top loop, makes a call to Retrieve Status Info. That VI has an output called Power and Errors. Kind of an odd combo, but anyway, in the same cluster is match info. I have never actually tested it at an event, but I suspect that the data will be in there. You could write it to your own file on the DB computer, or you can put it into Network Tables and give it to the robot.

Greg McKaskle

I think I found it!



WPI_DashboardProcessTCPPacket.vi, in red box at bottom left is the bundle constant which stores the default values. I surrounded the Event Info box with a red rectangle for emphasis, since I assume this is where the values are.

Sadly, there are no descriptions for any of these values (Name, Type, Number, Replay), whether they are base-0 or base-1, or what they refer to (what does type mean? does replay read 1 if this match is a replay?)

Anyway, in hopes of turning this into a VI for a robot target (rather than one for the dashboard) I sleuthed through the relevant code.

Apparently this method creates a TCP connection on port 1741 (at least for me) which then listens for requests; when one is received, it is sent through a local variable to the WPI_DashboardRetrieveStatusInfo.vi, where 10,000 bytes are read, then the data is sent to be processed by WPI_DashboardProcessTCPPacket.vi. It does some weird byte stuff that I can't for the life of me interpret, then it reads it, parses it, and passes it out through Power and Errors.

Would this work if I ported it to the robot, or are these port 1741 requests only sent to the dashboard?

[scca229]

Originally Posted by MasterEric

Apparently this method creates a TCP connection on port 1741 (at least for me) which then listens for requests; when one is received, it is sent through a local variable to the WPI_DashboardRetrieveStatusInfo.vi, where 10,000 bytes are read, then the data is sent to be processed by WPI_DashboardProcessTCPPacket.vi. It does some weird byte stuff that I can't for the life of me interpret, then it reads it, parses it, and passes it out through Power and Errors.

Would this work if I ported it to the robot, or are these port 1741 requests only sent to the dashboard?

The port 1741 part has me wondering if the robot would ever see it since that is not one of the ports that is white-listed through the FMS. Am I reading section 2.4 of the Game Manual correctly in this instance?

[Greg McKaskle]

Retrieve status info already returns the data. It is wired to the named unbundler at the bottom of the loop. It unbundles the Camera IP and robot IP, but not the other fields. If you grow it, or change robot IP, you can retrieve the event info cluster.

The picture you posted is of the implementation details. That is a constant that sets the feedback node storage the first time it executes. The TCP message shows up occasionally and is held onto by the shift register so that once seen, the return value remains valid.

The new or cached value is then passed by wire, not local variable, to a loop that processes a stream of mixed info. The 10,000 bytes is a max read, by the way.

As for sending to the robot, I'd just write this info to a network table variable. There is no need to make your own TCP connection for about ten bytes of data.

Port 1741: This is communicated on a local connection between the DS and DB. It is on the same computer 99% of the time, and if you are using two computers, it doesn't go through the field either, just between your computers. So the port is unlikely to be blocked. If it is, very little of the DB works already.

The info is not documented, but not cryptic either. The name will be some characters. It is short and understandable event name, but not a complete address or anything. Type will tell you what type of match it was. Number, the match number. Replay will increment if this is a replay of a previous match. I don't want to spoil all the decoding fun...
This data shows up in the log file viewer as the Qual 3-1, for example.

And bear in mind that this wasn't well tested. I expect it to work, and it was put there for this purpose, but to my knowledge hasn't been used yet. It's just like those special feature on your robot that "work" when you talk to other teams and judges, they just haven't been tested on the field .

Greg McKaskle