Announcing FRC Queue

@Koko_Ed, thoughts on implementing this for Ruckus?

If we can get it to work I’m all for it. A couple of years ago there was a GMS app available online but it required you being connected to FMS (not just wifi) which I was unable to do without help from the FTA who was busier doing other things on competition day. Is it going to be the same case with FRC Queue as well?

I don’t know the technical details. @forbes? Or is it easier just reach out by email?

@Koko_Ed, I don’t want to step on any committee toes, but I’m happy to reach out and try to coordinate something.

1 Like

I’m sure Jeff will appreciate it if you stepped up and signed me in. All he wants from me is to make sure the first match is on the filed and ready to go.


Sounds awesome! Being able to send texts like “Match 51 complete” and “After lunch, match 37 begins at 12:30” to drive teams (and other interested parties) to all interested parties would be a good start.
As far as travel goes, “burner phones” with the capacity for a few hundred texts can be pretty inexpensive, especially if set up by the event sponsor, who should be able to figure out a good provider.

  • How do people subscribe to the text stream?
  • When someone subscribes, can they enter a team (or teams) of interest, or is it generic to the event? If team specific, what’s the granularity (e.g. 3 matches ahead for drive teams vs 1 match ahead for family members watching the stream)?

Sounds great in theory but now you have the ‘we never got a text’ issue. Different number of cell carrier, different building structure/build materials/etc. You’re still going to need to have a volunteer queuer to avoid this issue so why we want to keep adding complexity to a problem that has a simple solution.

I think until the day where FMS or events (on/off season) can provide a wifi network that is separated and isolated and allow teams to be on there will be the better solution.

1 Like! No FMS connection is required, the system can be completely independent.


For this specific issue, the system supports up to 5 phone numbers per team for redundancy.

But in general, teams should never rely on a single method for queuing- you might miss a text, not pay attention to the pit announcement, or the pit queuer might go on break. That’s why FRC Queue also provides a real time dashboard that teams can monitor, and of course traditional queuing methods are always still available (just work with the Lead Queuer at your event to find the best solution for your team!).

1 Like

So basically, make sure the old fashion way is still available. So why add this layer of complexity? More things to have to deal with/make sure working?

Personally, if we had easy access to something like the text notifications I’d rather opt for using the notifications than pit queuer and pit announcemnts.

Even better yet, having a computer monitor displaying this dashboard in our pit would be amazing. Everyone in the pit could see it easily.

If everything works as intended, and a majority of teams see a benefit to using FRC Queue, then it would make sense to have both systems. The old system to fall back on and to provide a bare minimum to rookie teams/those without cellular data, and FRC Queue as a more elegant solution for teams to make use of.

Now, if events saw a vast majority of teams opting not to use FRC Queue, then I could easily see them not adding the complexity by not using it in the future.


Maybe let’s see how it works in practice during this off-season before declaring a “queue next match” button needlessly complicated?


“Why should we try to improve when the old fashioned way will still exist?”


Just don’t see how a solution that requires Network Access (or Cellular Network depending on how one defines it) will work across the board. Wifi is prohibited by rules for all Official Event (or at least they are up here in NE District) so until they changed it, it’s a no go. Cellular coverage is hit-or-miss. For example, during NE District Event at Seacoast (Pease but was redirected to a former warehouse in Durham, NH). Due to the warehouse all metal construction, there’s no cellular coverage anywhere 1’ inside the entrance door (you can asked anyone who attended).

I’m all for an improve on communication but I rather it be an official fully supported solution that will not potentially run foul of any rule (i.e. private wifi hotspot) or will have uneven have’s and have-not’s.

So a solution that just adds another layer of inefficiency just doesn’t seems like it’s going to improve anything to me.

1 Like

This is a wonderful thought but it’s worth understanding that much of what we all take for granted as being “core” to the FRC experience started out as a skunkworks project like this and have been moved into being “officially supported” and… often with a “begrudgingly” in front of it.


Because this is a value-added proposition. For most events this won’t be taking anything away. If events have super effective pit queuers that most teams appreciate (I’ve rarely seen this), then keep it. This adds value where there are no pit queuers or ineffective pit queuers.

WiFi is not what’s prohibited. Broadcasting your own network is. Lots of events have WiFi. Lots of events have cell service.

This is a beta. Don’t shoot it down before it’s even attempted.


No, having private Wifi (hotspot off your phone or run it out of your pit), regardless whether you open broadcast it or not is illegal because you are introducing interference to the official FMS signal band.

1 Like

Yes that would be broadcasting your own…

Which is what he said.


Yep, that’s what he said.

Using venue-provided Wi-Fi is not illegal, however.


The FRC Queue team guide is now available which should answer most of the common questions: FRC Queue | Team guide

All details are subject to change based on feedback from trials- the first of which will be next weekend at the Texas Robotics Invitational!


Team Queuing at events can definitely be made better. I wish you success at the Texas Robotics Invitational. I look forward to hearing your impressions of the system after the event.