Inspired by this thread. Poll above. Should FIRST make match data such as score, pressure built, rotors turning, time, etc. accessible by the robot? Vote and leave your thoughts below.
Some pros:
Some cons:
This is the biggest reason to do it. I mean, all the stations can pretty easily see the time on the loading station nearest to them, but having the score obscured is rather annoying.
I said yes, but that’s with a caveat… not every year is like this year, with almost all automated real-time scoring. When we have games where there’s a high degree of confidence that the score being sent isn’t going to be changed retroactively, I think it’s a great idea. It’s one thing to have a possibly incorrect score displayed on a screen way above the field that the drivers might not notice, it’s another to have it right in front of them in the driver station. I did notice at Iowa this year that the screen was positioned behind one of the drive teams, which is rather uneven for tracking the score as the match progresses.
There’s also a question of how much data to make available. For example, if the number of rotors shown was incorrect, it could drastically affect your strategy mid-match and change the outcome of the game. I don’t think any of us want that 
Slight modification - instead of it being accessible by the robot, I’d prefer if there was just a tab in the driver station that mimicked the score display that is shown on the broadcast.
Is there even a way for the drivers to know current field pressure other than reading the gauge on the side of the boiler?
More data can’t hurt, especially if it’s marked as “live” or “unofficial”.
Plus, it’d be kinda cool to get match score changes in real time. (You could also in theory infer alliance fuel rate)
If FIRST chooses to keep it as is, there isn’t much we can do to fix it, but having a live scoring view on the DS would be pretty useful / neat.
The only other place to look would be the scoreboard, which is often much more difficult to see for one of the two alliances.
I love this idea. One of the other main reasons I brought this up is because I know that at some events the fuel gauge on the airship doesn’t work.
No, I don’t think it should.
This will require a partial protocol overhaul every year, and will make working with the robot with a standalone driver station more troublesome. You’ll be using up more bandwidth, but honestly that part is the least of the issues.
Probably the biggest point is that this WILL GIVE AWAY THE GAME BEFORE KICKOFF. This implementation requires an effort from WPILib to implement some kind of API the programmers can access. Making this the score breakdown, you will have to change the code each year. Since WPILib is open source and available prior to kickoff, you can see what would happen.
Scores aren’t officially committed until the end of the match. If you’re pushing a score at face value (e.g. just the alliance score with no breakdown), it’ll be put in the same category as match time, not official and you can expect it to be off by a considerable margin. If you want a score breakdown, you will find many categories (e.g. touchpad triggers) cannot be resolved to your robot.
The FMS doesn’t communicate to your robot directly. If this were to happen, it would bounce from the FMS to your DS, and then to your Robot. Apart from the obvious, you’ll be relying on the driver station to compile the score breakdown into what will likely be NetworkTables. FMS is designed to not do this, it does not touch your NetworkTables traffic, nor any of your traffic. It tells the Driver Station what to do, and ultimately the Driver Station has the authority.
The match time, alliance and alliance station values are coupled in with a special packet being sent to your robot at a constant rate. Including score breakdowns will inflate this packet massively and, as previously mentioned, require a protocol rework every year.
Overall, this change is going to require major work across seasons from the FMS team, the WPILib team, and everyone else involved, which breaks compatibility. If you’re suggesting just the match score on its own (i.e. red 200 blue 150), it shouldn’t be too big of an issue.
Wouldn’t they be able to branch off their public repository and just re-merge after kickoff?
Alternatively, rather than releasing methods like getRedScore(), getPressure(), etc. you could just call them getMatchData1(), getMatchData2(), etc. and then release which methods correspond to which values on kickoff.
That defeats the purpose of having an open-source project, and is messy to say the least.
Possibly, but they want beta teams to test it out first, especially if it keeps being rewritten every year.
I think a good way to do this would actually be to have a JSON or XML file hosted on the FMS (accessible through a single IP that can’t be a team’s IP, like 10.100.100.2/scoreboard.json or something) and have teams write their own code to work with it.
I could be persuaded to not add breakdowns, although it would be cool to squirt water at the drive-team every time the fouls points increases on the opposing alliance :P.
Why couldn’t there just be a JSON string of score that is defined the the protocol and day 1 we get the definition of the structure of the JSON string, kind of like the score breakdown JSON from thebluealliance api.
That’s sort of what I was thinking. Even if different data types were required, could always pack the data into a four byte array and unpack at the driver station. As far as passing the data to the robot, I think this should be up to the teams on whether they do it or not. Giving this information to each driver station though would be helpful to everyone. Even if the scoring real time isn’t accurate, it’s still useful 90% of the time for making decisions in real time.
Huge monolithic merges is what Google does with there Android AOSP repository.
They seem to do well for themselves and it seems not to defeat the purpose.
It is of course messy. But in this case it would only be messy once a year.
FMS’ internal field web interface would be the wrong choice architecturally, especially given the small time constraints of a match. (Imagine a TCP request hangs for 30 seconds and then times out - that’s a fifth of the match!). Additionally, the web interface is a C# .NET project. A malicious team could DOS the webapp and potentially prevent field staff (CSA’s and FTA’s) from responding to robot control issues other teams are experiencing during the match. Plus, I’m not 100% sure, but I believe there’s a separate VLAN for field staff and their devices with different QoS settings. Teams are given a restricted VLAN that’s discussed in the ever-classic and ever-outdated FMS Whitepaper.
The right model, network-wise, would be an additional UDP packet thrown at the RoboRIO (one that’s separate from the heartbeat). In fact, they could even reuse the JSON format used by the frc-events API, and simply repackage it in a more compact format like msgpack. That way teams can just be given a generic dict from WPIlib, and are left to their own devices to interpret the score breakdown.
UDP thrown mercilessly at logging endpoints is a pretty typical pattern these days, similar to the ELK stack used by many hip web startups.