Well, if it’s actually readind the match data from a livestream, just get the current time since start, and use it to create starts and stops, and then you could run it through ffmpeg to extract only the start of a match and the end (plus or minus like 5 seconds I suppose.)
I’m looking at it like a programmer, but this overall is awesome!
Score screens in the DS wouldn’t work. Unless I’m mistaken, driver stations don’t have access to the internet during a match, and even if they did, there would be a huge lag. Also, this would probably blow out your bandwidth limit.
Not to mention it’d be easier for the field to simply provide access to scores the way they do with time and alliance and position and y’know.
I mean for events to be able to set up screens to be used by teams. Not for teams to have their own.
Got it. Thanks for clearing that up.
This looks really neat. I am looking into parsing rotors/balls/climbs scored and maybe teams on both alliances as well. I am wondering if maybe if the OCR can be used to read how many exact gears are on an airship for semi-automatic scouting (however this might be too inconsistent).
I don’t think exact gears are possible, but interpolations from rotors would be. You could from the times and rotors derive a gear scoring rate. There would be some problems still because of the unequal tiers. The first rotor rate wouldn’t be reliable because it doesn’t take multiple gears and is automatic. The fourth rate wouldn’t always happen. So you might need to take some average of the 2nd and 3rd rotor rates. You also then have to deconvolute this to make it a team-based rather than an alliance-based rate.
I’d researched ocr’ing the stream (for gear rates), so I’m glad someone has at least done it for the score. I’d found this example: https://waldo.jaquith.org/blog/2011/02/ocr-video/, but didn’t get very far. I basically reached the part before the Tesseract part, but I wasn’t processing the stream in a systematic way. I hadn’t yet figured how to start/stop the match time. The background color changes throughout the match and at key times, so that was where I was thinking I could key onto (like the color change at 30 seconds remaining).
It’s now spamming twitter at @FRClivescore](https://twitter.com/FRClivescore). Please report any incorrect scores if possible! It seems like it’s most inaccurate with the blue score at the moment, occasionally appending a number at the end.
Just kidding… I’ll set it up on a Raspberry Pi tonight and get it up and running on Twitter for tomorrow.
With a huge amount of help from Eugene Fang, the 2018 version of FRC Livescore is ready to go for the season. There are a ton of new changes for this latest version, including (but not limited to):
Some of you may have already seen this in Week 0, but FRC Livescore is now being used on The Blue Alliance to show the real-time scoreboard on an event’s page! This feature is still in the very early stages and is subject to change as the season progresses, but it’s a very cool use of this technology and am super excited for it to be used during the season. It should also provide us with some unique statistics about matches this year, and how different ownership times affect the outcomes of games.
Thanks to everyone who has contributed to make FRC Livescore amazing! Check out the latest version on GitHub: https://github.com/andrewda/frc-livescore.
Finally, here are some example images using the new FRC Livescore (from 2017 and 2018):
Wait…why isn’t this a thing???
We thought it was going to be a thing when FIRST announced field state info… Turns out that was just LLL/RRR/LRL/RLR. 
But at least the infrastructure is there now for future games… maybe…
Are there any plans to have this data accessible via TBA’s API?
The LLL/RRR/LRL/RLR data, or the Livescore data?
Andrew & Eugene, This is really fantastic work! I’m definitely interested to see where you go from here, particularly the integration onto TBA.
Can you share more details on what you are doing to implement this from the live stream?
Livescore data
Yes, we plan to make the data available.
The current plan is to deploy workers onto Google Cloud Platform (where the rest of TBA runs) for each ongoing event. Each worker will monitor the webcast video stream, run FRC Livescore, push live data to TBA, and save data to a SQL database.
The backend code is here, and is still a work in progress. 3 more days.
Cool
Eugene summarized the gist of it and I’ll be sure to write a tech talk on the TBA blog once I finish up all the infrastructure work.
The plan is to add some APIv3 endpoints for querying the realtime data. https://storage.googleapis.com/tba-dev-phil.appspot.com/2018week0_backfill has a SQL dump of backfilled week0 data if you want to play around with it (not 100% correct and subject to change, but it’s a start).
Don’t remind me. Soon™ :yikes: