[FRC Blog] Event Results and API Data

[efoote868]

As a remote spectator, I was disappointed that I could not find a qualification schedule for my former team, and as a result I watched less than I have in years past.

[Bryan Herbst]

Originally Posted by lynca

The playoff display is too complex. It's difficult to determine who actually won the playoffs.
http://frc-events.usfirst.org/2015/TXDA/playoffs

They need to simplify to something similar to the TBA format.

http://www.thebluealliance.com/event/2015txda

The FRC website is actually doing this more "correctly," though neither are providing an accurate picture of what is happening. In qualifications, quarterfinals, and semifinals, neither alliance "wins." It is all based on average score for these rounds.

It would be nice if the FRC website highlighted who won the finals though, and both should more clearly highlight the teams that move on to the next round throughout playoffs.

As for Cheesy Arena:

Keep in mind that Cheesy Arena is designed for offseason events that don't have the team number signs, the team lights, emergency stop buttons, alliance station lights, SCC (alliance scoring cabinets), any game-specific field hardware (e.g. goal lights in 2014, weight sensors in 2013), ref panels, or any other miscellaneous field hardware that typical comes with a FIRST event.

It may be open source, but it also has far fewer moving parts to deal with.

[Eugene Fang]

Originally Posted by Tanis

The FRC website is actually doing this more "correctly," though neither are providing an accurate picture of what is happening. In qualifications, quarterfinals, and semifinals, neither alliance "wins." It is all based on average score for these rounds.

Except the FRC website doesn't show the average scores, but The Blue Alliance does.

The bolded "winning" team on The Blue Alliance will be removed for non-finals matches.

[Bryan Herbst]

Originally Posted by Eugene Fang

Except the FRC website doesn't show the average scores, but The Blue Alliance does.

The bolded "winning" team on The Blue Alliance will be removed for non-finals matches.

Ah, I was just looking at the match results and somehow missed the playoffs breakdown on TBA. That is definitely more useful.

[Kevin Sheridan]

Originally Posted by Tanis

As for Cheesy Arena:

Keep in mind that Cheesy Arena is designed for offseason events that don't have the team number signs, the team lights, emergency stop buttons, alliance station lights, SCC (alliance scoring cabinets), any game-specific field hardware (e.g. goal lights in 2014, weight sensors in 2013), ref panels, or any other miscellaneous field hardware that typical comes with a FIRST event.

It may be open source, but it also has far fewer moving parts to deal with.

Cheesy Arena handles most of this stuff and was designed around using readily available hardware to display things such as team numbers. It even improves upon the game specific elements like the hot goal lights, which were actually timed correctly in Cheesy Arena.

[Bryan Herbst]

Originally Posted by Kevin Sheridan

Cheesy Arena handles most of this stuff and was designed around using readily available hardware to display things such as team numbers. It even improves upon the game specific elements like the hot goal lights, which were actually timed correctly in Cheesy Arena.

Yes, it does provide most of things in forms other than what we are used to at FIRST competitions.

However, FIRST is unlikely to completely replace the existing hardware in the very near future. Additionally, while Cheesy Arena is an excellent substitute for the FMS for offseason events and the cost of the overall system is lower, FIRST has a different set of requirements for the official field.

For example, the GitHub page for Cheesy Arena explains that Chezy Champs used cheaper consumer-grade LEDs instead of the professional grade LEDs used on the official field.

I am not privy to the decision making process that goes into selecting the components for the field, and I'm not making any arguments for which software or hardware is better. What I'm saying is that Cheesy Arena isn't designed to be a replacement for the FMS during competition season, and isn't likely to become a replacement there.

[Basel A]

I'm not sure whether or not open source FMS is a good idea yet. Certainly I think the community would be very on board with helping out. One additional point: wouldn't open-sourcing FMS open FIRST up to 2012-style sabotage?

[Eugene Fang]

Originally Posted by Basel A

I'm not sure whether or not open source FMS is a good idea yet. Certainly I think the community would be very on board with helping out. One additional point: wouldn't open-sourcing FMS open FIRST up to 2012-style sabotage?

The best security is achieved when everyone can see the problems and then fix them, not through obfuscation. Security achieved because "no one knows how our internals work" is bad practice.

[Rachel Lim]

Originally Posted by Basel A

I'm not sure whether or not open source FMS is a good idea yet. Certainly I think the community would be very on board with helping out. One additional point: wouldn't open-sourcing FMS open FIRST up to 2012-style sabotage?

Originally Posted by Eugene Fang

The best security is achieved when everyone can see the problems and then fix them, not through obfuscation. Security achieved because "no one knows how our internals work" is bad practice.

Although it's not a perfect analogy, this sounds like various Wikipedia debates I've heard. On one hand, letting anyone edit pages leads to incorrect/biased information, sabotaged pages, and edit wars. On the other hand, Wikipedia is one of the largest, easily accessible sources of information--and most of the time other editors fix incorrect information.

Without any relevant experience, my guess on this would be that if FIRST decides to open source it, they open up the possibility that experienced mentors and students are able to help. However, they also open it to the risk that anyone can sabotage it if they like. Of course, there are far worse consequences to this than just a sabotaged Wikipedia page, which FIRST has to consider carefully.

[Eugene Fang]

Originally Posted by Rachel Lim

Although it's not a perfect analogy, this sounds like various Wikipedia debates I've heard. On one hand, letting anyone edit pages leads to incorrect/biased information, sabotaged pages, and edit wars. On the other hand, Wikipedia is one of the largest, easily accessible sources of information--and most of the time other editors fix incorrect information.

Without any relevant experience, my guess on this would be that if FIRST decides to open source it, they open up the possibility that experienced mentors and students are able to help. However, they also open it to the risk that anyone can sabotage it if they like. Of course, there are far worse consequences to this than just a sabotaged Wikipedia page, which FIRST has to consider carefully.

It's important that to note that "open source" does not mean anyone can make edits without review, potentially allowing the system to be "sabotaged." Changes must still be reviewed and then accepted by the owner.

[dcarr]

Originally Posted by Eugene Fang

It's important that to note that "open source" does not mean anyone can make edits without review, potentially allowing the system to be "sabotaged." Changes must still be reviewed and then accepted by the owner.

This. It's surprising how some people on this thread don't seem to understand how typical open source development works. It's not like we're suggesting FIRST make the repo public, accept all pull requests, and then just build and use whatever's there come competition season.

FIRST is likely very limited in the number of software engineers they can hire. Based on some of the technology stack being used, it's likely that FMS continues to utilize legacy code that's been around for a while. As Cheesy Arena demonstrates, a fresh approach using modern technologies can have great results.

Open sourcing FMS and creating a community advisory board could allow recognized developers to contribute to FMS and improve quality more than FIRST's in house developers could do on their own.

The biggest potential obstacle in making FMS an open source project might be the risk of potential game leaks. One possible approach could be to keep source closed closed during initial development and release the source once kickoff occurs. Then, feedback and community improvements could be put towards the next release. Android works in a similar way; each new version is developed internally by Google, then released to AOSP when it is announced publicly. OEM partners and community members can submit fixes which are then rolled into point updates or put towards the next version of Android.

[George Nishimura]

I echo the calls for open sourcing FMS.

Originally Posted by Eugene Fang

The best security is achieved when everyone can see the problems and then fix them, not through obfuscation. Security achieved because "no one knows how our internals work" is bad practice.

Originally Posted by Eugene Fang

It's important that to note that "open source" does not mean anyone can make edits without review, potentially allowing the system to be "sabotaged." Changes must still be reviewed and then accepted by the owner.

This and this.

Open Source does not mean there is not a core group of developers committed to working on it for a deadline. It just opens it up to the possibility that extra pairs of hands/eyes can be volunteered.

Open-sourced software does not make it more vulnerable to security flaws; in fact, if the community is strong enough, it can lead to even better security. Again, another set of eyes/hands to spot and fix those security, performance and scalability issues.

One could argue that FIRST should make FMS Free, not just Open Source, Software, but one step at a time I guess.

[plnyyanks]

I also agree with the idea of a greater open-source initiative on the part of FIRST.

Open source has become huge in the CS world recently; and one reason is because of all the advantages it provides. FIRST's development team can remain "benevolent dictators" of their code, just like Linus is with the Linux kernel - contributions may be submitted by anyone, but only the worthy get merged in. I think that the community is dedicated enough to make meaningful contributions back upstream - and this benefits everybody.

Many people also regard the field software as a "mystery box" and have no idea how any of it works. An open code base will let people understand how the field functions, because they can peruse the code themselves. I think this might reduce some of the anger we've seen in recent years - this weekend's API issues and last year's delayed pedestals and hot goals come to mind. Who knows, maybe somebody in the community would have spotted an optimization that could have fixed the problems quickly. Often, a new set of eyes is all you need to spot errors (my favorite tactic is to Rubber Duck Debug with a stuffed tux toy on my desk).

I can, however think of a few drawbacks. Mainly developer time. I can only imagine how stressful being a developer at FIRST (it's a pretty small team, too) is this time of year, and adding in a responsibility to watch a public repository can be a lot. However, most of the main contributions can come back in the offseason, when they have more time. An open source repo also shouldn't contain any advance information about the next game. I liked the suggestion above about following the Android model - code doesn't have to be pushed to the repo until kickoff.

To me, the benefits of a greater open source involvement far outweigh the cons. I know that if the FMS API was open source, I would have spent a significant chunk of time this weekend helping debug it, and I would have been happy to help contribute fixes. Plus, FIRST could set a great example for teams by promoting open code; something all computer science students should have experience with when the enter the real world. FRC already gives so many positive experiences, this is another one that could make a great difference.

Plus, GitHub has a much better UI than TeamForge...

[nathanwalters]

Originally Posted by plnyyanks

Plus, GitHub has a much better UI than TeamForge...

This alone should be enough of a reason to switch to a different release model. TeamForge is one of the worst pieces of software I've had the misfortune to work with

[Jared Russell]

The model used by WPI during control system beta tests would be another possibility. In this model, access to source is granted to a select group of vetted individuals during development in order to move fast and avoid buggy or incomplete code from making its way into teams' hands. Once a stable version is available (such as at the beginning of the season), source is released to all comers, and bugs may be filed or patches proposed using online tools.