Programmatically get match number from FMS?

Technical Programming
1

Hi,

I’m wondering if there’s any way to programmatically get the match number for the current match from the FMS. I’ve looked at the DriverStation class in WPILib, which provides an API to get the alliance colour and driver station number, but as far as I can tell doesn’t provide the match number. This seems strange to me, as the driver station shows this information on the screen.

I also see that there’s a MatchType_t enum in allwpilib/ni-libraries/include/FRC_NetworkCommunication/FRCComm.h which looks somewhat like what we’re looking for, but I’m not sure if that’s actually sent over to the robot, or what the implementation of that would look like.

Does anyone know how we can get the match number programmatically?

Thanks.

2

According to FMS whitepaper, the field does not send the match number to the robot, although it does not specifically say what is sent to the robot. (So YMMV)

Frequently Asked Questions
Does FMS control the robot?
No, FMS does not communicate with the Robots directly. On the playing feld, FMS communicates
exclusively with each DS, sending it commands for enable/disable, auto/teleop, Estop, player
station number and alliance color. The DS then sends this data to the Robot.

And

What information does FMS log?
FMS combines the status data from each DS along with the data that is monitored from the feld
components and stores this data in log fles. The following data is logged every 500ms for each of
the six Robots on the playing feld during each match:
• Timestamp (local time)
• Match Number
• Team Number
• Match Time
• Alliance
• Mode (Auto/Teleop)
• DS in FMS Mode (yes/no)
• Robot Mode (enable/disable)
• Estop state (on/off)
• Robot Link (yes/no)
• Bandwidth consumption over the wireless link
• Strength of the signal transmitted by the Dlink radio
• Signal-to-Noise Ratio of the wireless link
• Average packet trip time between DS and Robot
• Number of missed packets between DS and Robot
• Total number of packets sent by DS to Robot
• Robot Battery Voltage
• Blue SCC connected (yes/no)
• Red SCC connected (yes/no)
• Blue Scoring I/O connected (yes/no)
• Red Scoring I/O connected (yes/no)

3

The match number is in the Driver station logs, so it at least gets sent from FMS to DS.

4

I wouldn’t trust that white paper at all. I know it’s well intentioned but it’s not accurate or complete. It’s not a complete description of the field network for one. We’ve been doing some research into the FMS network this year after our troubles in Blacksburg and I’m not yet sure how we’re going to release our findings but I can tell you that white paper is incomplete and outdated at a minimum.

I would really like to see a complete breakdown of the field network including part numbers and configurations, along with the APIs for FMS being properly documented.

I’ve said it once and I’ll say it over and over until something changes, FMS is a black box, treat it like one.

5

Yes, but pretty sure it does not get sent to the robot. (At least not 3 years ago, when we looked in earnest.)

We log on the robot every 100ms, to a csv file, and it would have been really nice to have the filename to be a match number, if we were playing in an actual match. We tried to find this data on the bot, but were not able to.

We now just sequentially increase a log file name and save it as a text file on the roborio, once we pull the log files, it is pretty easy to figure out by size, which files are actual log files, and which ones are from the pits.

6

The FMS in the whitepaper is the idealistic representation of the FMS in the abstract… multiple years ago. The FMS whitepaper is to the FMS as a week 1 robot design is to what your final fielded robot.

7

I agree. As another team that has been plagued by “stuff” working in our shop, and go to an event, and have much of a teams hard work squashed, after following the published directions, is really unacceptable, and not inspiring.

Our last years vision processing, this years USB driver feedback, and this years vision processing, have all be broken by the field FMS, after following all of the published methods and configurations. FTA’s and CSA’s are great and help, but still did not solve the issues we have come across the last years. We are doing vision on the roborio, not even adding a 3 party to the control system.

8

Unacceptable is a good word for it, as is uninspiring (I looked them both up in the 2017 Q&A guidebook - No Frank, I’m not letting that go yet.).

I’m going to bow out of this thread before I go on an obnoxiously long rant about FMS. The lack of proper documentation for this is not only infuriating but the fact that volunteers and staff continually blame teams when the issues are very often with the field is alarming. COUGH 2017 radios and that second port not working COUGH

I will also add that the 2012 shenanigans directly resulted in the original white paper, which hasn’t changed much despite the field network changing almost yearly. It would help to avoid any future shenanigans by making the configurations less of an unknown.

9

I would surmise that part of this abstraction is to attempt to prevent Einstein 2012 incidents from happening again.

10

This is part of my understanding as well. To put things so verbosely also give an easy road to test in secret and rip the FMS to shreds, or rather, the weakest link attached to the FMS.

EDIT: Others are pointing out that security through obscurity is a bad practice, and I absolutely agree. You’re also assuming that anything that FIRST does follows common practices…

11

Security through obscurity is considered to be a bad practice by many security experts.

12

Security by obscurity is insufficient.

13

Curious, what broke?

14

This is something we’ve looked for in the past. Unfortunately, the MatchType_t enum is entirely unused, and serves no purpose. The match number is not sent to the RoboRIO, however with some effort from parsing DS logs you may be able to cross-reference your RoboRIO with your Driver Station since the RoboRIO is configured to use the Driver Station’s date/time at first connection.

15

We looked high and low for the same thing and couldn’t find it. Bummer, because we have been doing some pretty extensive logging stuff and it would be nice to have that included.

I’m intrigued and excited to read your findings.

Yeah, but that didn’t happen because someone had extensive knowledge of FMS and knew how to exploit it (if my memory serves), it was just a guy who found a bug through trial and error. I don’t think a single incident should keep all of the info in the dark.

16

It would be fairly simple just to add a smartdashboard field that lets you type in a natch number or other prefix to the file name for logging purposes.

17

Yep, we’re also looking for this for logging. Right now we’re just using the unix timestamp as the name for the log folder. One idea that we had for determining if it is an official match is to use isFMSAttached() to make symlinks to the official matches in the form of 'fms_n` where n is an incrementing number.

Alright. Good to know that other people have come to the same conclusion, although it sucks that there isn’t a clean way to get it.

Yep, that’s essentially what we’re planning on doing…

Sucks that it isn’t actually available automatically though.

18

If it displays on the Driver Station, then you can write a program to read the display and send that info to the RoboRio.

That is sort of how we got vision to work last year. Looked at the feed of an IP Camera.

19

You can get the match number and level by reading the latest dsevent file and looking for the following text depending on the match type.

FMS Connected:   Qualification - ##
FMS Connected:   Elimination - ##
FMS Connected:   Practice - ##
FMS Connected:   None - ##
20

You can get the match number and level by reading the latest dsevent file and looking for the following text depending on the match type.

Could you elaborate on what “the latest dsevent file” is and how to get it? I’m assuming that’s Driver Station EVENT…