[FRC Blog] Event Results and API Data

[Hallry]

Posted on the FRC Blog, 2/28/15: http://www.usfirst.org/roboticsprogr...s-and-API-Data

Event Results and API Data

Blog Date: Saturday, February 28, 2015 - 13:29
Today’s brief blog is from the FRC software team:

We are aware of tournament data not publishing consistently for all events. The root cause has not been determined, and at this point, we don’t expect resolution for week 1 events. Because of this, developers relying on this data for their own applications will not be able to relay the data on our behalf. This issue only inhibits the data being reported out by events, and the results and rankings reported at events are unaffected. Please accept our apologies for any frustrations.

[Nathan Streeter]

Very, very, very frustrating, but at least glad FIRST still has all the data...

[Eugene Fang]

Originally Posted by Nathan Streeter

Very, very, very frustrating, but at least glad FIRST still has all the data...

Do they?
http://www.chiefdelphi.com/forums/sh...4&postcount=23

[Katie_UPS]

Originally Posted by Eugene Fang

Do they?
http://www.chiefdelphi.com/forums/sh...4&postcount=23

If it is stored locally (which it clearly is, as the event needs to data to generate rankings and such), then there is no reason it has to be lost.

[AdamStockton]

Originally Posted by Katie_UPS

If it is stored locally (which it clearly is, as the event needs to data to generate rankings and such), then there is no reason it has to be lost.

Yes, it is stored locally. I volunteered as a scorekeeper for an off season event last October, and the match data (and settings) were backed up automatically after each match. There are also means of exporting it as well.

[Kevin Sevcik]

Originally Posted by AdamStockton

Yes, it is stored locally. I volunteered as a scorekeeper for an off season event last October, and the match data (and settings) were backed up automatically after each match. There are also means of exporting it as well.

New software this year, though. If we were running last year's software and API, we wouldn't be having these problems.

Also, even if the data is stored locally, that's no guarantee it's going to be pushed out and made available via the API after these events are over.

[AdamStockton]

Originally Posted by Kevin Sevcik

New software this year, though. If we were running last year's software and API, we wouldn't be having these problems.

Yes, it is a different FMS software this year. However, each version of FMS seems to be based off of the previous season's version (with improvements and game specific updates). I don't think they would have eliminated the backup system, since that is a pretty important feature.

Originally Posted by Kevin Sevcik

Also, even if the data is stored locally, that's no guarantee it's going to be pushed out and made available via the API after these events are over.

It is true that there is no guarantee that the data will become publicly available, but at the very least the district results need to be available. This data is vital to calculating the district rankings for each district team that competed this year.

[plnyyanks]

Originally Posted by Kevin Sevcik

Also, even if the data is stored locally, that's no guarantee it's going to be pushed out and made available via the API after these events are over.

This is based on my recollection of last year's FMS software...

I think that getting the data off would have to be a manual task. The database backups will definitely exist on each scorpion case, but I don't know if the functionality exists to automatically upload old data (or if you can even do it at all, once the event wizard is complete). The solution might be to remote into each field (ugh) and copy of the backup files. Or, have the Scorekeeper at each week 2 event export a bunch of csv reports, which can be imported. Doesn't seem like very good options, especially when the blog post didn't give a time frame for a fix. I wouldn't be surprised if it's not up for Week 2, either...

[Basel A]

Originally Posted by AdamStockton

Yes, it is a different FMS software this year. However, each version of FMS seems to be based off of the previous season's version (with improvements and game specific updates). I don't think they would have eliminated the backup system, since that is a pretty important feature.

To my knowledge, FMS has been completely rewritten since last year.



I'd be surprised if there were any FTA across the country that wasn't aware that these problems were occurring. I would hope that they'd have the presence of mind to throw the data on a flash drive and/or send it manually to FIRST for reporting/archival.

[Bryan Herbst]

Originally Posted by Kevin Sevcik

New software this year, though. If we were running last year's software and API, we wouldn't be having these problems.

Also, even if the data is stored locally, that's no guarantee it's going to be pushed out and made available via the API after these events are over.

The software is "new" in the sense that it has been updated since last year, but the core functionality is mostly the same as last year. They started with last year's code and updated it for this year.

I'm not sure about your comment about last year's API- The only "API" available last year from FIRST was a webpage that third parties could scrape (which isn't really an API). This is the first year a true API has existed.

I'm not sure what the plan is for data that wasn't already posted, but I wouldn't be surprised if FIRST put in the effort to upload it.

[RyanShoff]

First opensourcing all the code they own would increase the quality of a lot of things.

[Doug Frisk]

Originally Posted by RyanShoff

First opensourcing all the code they own would increase the quality of a lot of things.

That's a mighty bold statement. Pretty much totally wrong, but mighty bold.

Open source is essentially useless in an environment with forced deadlines.

[SoftwareBug2.0]

Originally Posted by DareDad

That's a mighty bold statement. Pretty much totally wrong, but mighty bold.

Open source is essentially useless in an environment with forced deadlines.

Please tell us more about how allowing more about how the code getting more scrutiny ahead of time would make it worse. Can I sign up for your newletter?

[EricH]

Originally Posted by SoftwareBug2.0

Please tell us more about how allowing more about how the code getting more scrutiny ahead of time would make it worse. Can I sign up for your newletter?

There is a difference between open for scrutiny and open source.

If I put a document in a PDF and send it to you for you to review, that is open for scrutiny. If, however, I simply put the same document in GDocs and send you the link--with full editing permissions--that is open source.


In code, open source could be pretty bad, DEPENDING on a number of factors. Particularly, comments and other documentation, work breakup, and even "code styles".

But having the code open for scrutiny--that might help.

[Doug Frisk]

Originally Posted by EricH

There is a difference between open for scrutiny and open source.

If I put a document in a PDF and send it to you for you to review, that is open for scrutiny. If, however, I simply put the same document in GDocs and send you the link--with full editing permissions--that is open source.


In code, open source could be pretty bad, DEPENDING on a number of factors. Particularly, comments and other documentation, work breakup, and even "code styles".

But having the code open for scrutiny--that might help.

Pretty much this. Because the FMS has to be built and fixed on a deadline, an open source model, where you are depending on people who have no reason to meet an arbitrary schedule or work on "uninteresting" bugs to work to a schedule and fix the uninteresting bugs.