FIRST has released a RFP for the 2027 FRCFIRST Robotics Competition control system AND the 2027-2028 FTCFIRST Tech Challenge control system. Seems like this may have some substantial impact on how we see both FTCFIRST Tech Challenge and FRCFIRST Robotics Competition interact in the future.
FIRST is seeking a new Mobile Robot Controller (MRC) to serve the needs of both the
FIRST Tech Challenge and FIRST Robotics Competition programs. The supply
agreements/lifespans for the existing Mobile Robot Controllers (MRC) for each program
expire around the conclusion of the 2026-2027 seasons, and FIRST is searching for a
solution for the 2027 - 2030 seasons (or longer). The chosen controller will need to
support a team population of approximately 20,000-35,000 teams serving approximately
250,000+ youth and 50,000+ mentors per year across both programs over the lifetime
of the system. FIRST seeks a partner or suite of partners to provide design,
manufacturing, documentation, software, sales, and RMA support for all devices.
Still crossing my fingers for the return of mini-bots one day.
Is your company currently involved in any litigation in which an adverse
decision might result in a material change in the company’s financial position
or future viability?
I think this is a fantastic RFP and I’m glad FIRST listened to a lot of community feedback on it. Can’t wait to see the proposals (assuming any get made public) and what we end up with.
On a more personal note, if anyone is bidding and would like to engage me on consulting or advice, reach out - I’m happy to chat and work with you.
Im at work right now and have just skimmed through the RFP, so forgive me if this is clearly answered deeper into the document.
I can’t quite tell, is FIRST requesting a new Mobile Robot Controller that works for both FRC and FTC? ie, running a roboRio for both FRC and FTC control systems?
Of note to me is the requirements that maximum volume requirements of 60 inches^3 for total required system functionality (as in, a complete control system that does everything). This would rule out at least one past bad offender at space utilization:
(What you’re seeing here is about half of a full Modern Robotics control system – there’s only four motor ports and no robot control phone.)
I’m excited to see a non-Android, WPILib based platform for FTCFIRST Tech Challenge but I amAndyMark a little concerned about the transition – while the program runs on Java, our libraries and interfaces are completely different.
I’ve posted about the needs, wants, and past trauma (of which there’s a non-negligible amount of) associated with FTCFIRST Tech Challenge control systems here:
…And if you are working on a bid, I would be more than happy to chat or work together.
I would have expected the RFP to include requirements for a QA program and after sales support (not just warranty replacement). Those are two items that a smaller company bidding on these devices will struggle with I think.
On the other hand, I’m pleased to see FIRST left a lot of time (and hopefully money) in the schedule for a few rounds of testing and revisions after final selection. It’s nice to see an RFP that recognizes that a perfect product can’t be built in one attempt.
I don’t like that they included “Terminals used should facilitate tool-free wiring (e.g. lever or push-button style) or the use of pre-fabricated cables” in the 4.3.4 Terminals section, as I think robustness should be promoted over tool-less designs for robotics (i.e. pin box housing connectors are awful).
Fun, though I don’t think that fits within the min specs of MRC19 and MRC20
The 2 USB 3.0 (MRC35) and the 2 CAN buses (MRC38) will be a nice improvement.
Im so glad I ended up calling the CAN FD support. Unfortunately there is a lot of stuff that is preferred. So who knows exactly what will end up coming out of it. Having more than one can bus is exciting though.
This RFP is much wider ranging than I expected. Built in AprilTag processing will be super useful for many teams, along with 4 USB Ports. I think 8 Mbps CAN-FD is a little excessive and could lock out options that otherwise suit the requirements (many cheaper controllers can support 4Mbps only), especially with 2 busses, but other than that, looks like teams will be getting quite a package for $450 in 2027.
Im not sure if I am reading into the spec too much but the way I read it was at Min 2 can busses, where either could be 1Mbps or 8Mbps can FD. Would be cool if they where backwards compatible, and I do slightly agree can-FD might be a bit overkill. I think Id prefer 4 can 1Mbps busses over 1 can FD bus. Love the idea of being able to have failover busses. IE running half of a tank drive off of one can bus. That way if you loose one you just loose half motor power, not control. That said there is some protocol specific niceties with CAN-FD that the 1Mbps version does not have so it isnt just about speed.
Edit: A lot of the cheaper hardware does have hardware support for CAN-FD just not software support. So having native Can-fd support on a controller may make enabling that functionality worth the development time.
Looking at the current FTC control system, the expansion hub and control hub costing ~600 USD, I think the 450$ price point is EXTREMELY aggressive.
I wonder what HQ will actually chop off to meet something viable for both. No way you are getting everything “mandatory” in this RFP. At least the goals in this one are achievable compared to the radio RFP, just not at this price point (spec and IO wise, we’re looking at a Jetson with electrical and shock resistance, at a quarter of the price).
I think the multiple bus requirement is a smart choice from HQ. The 1mbit CAN bus would support every CAN device currently permissible on an FRC robot today. While some of those devices reportedly have CAN-FD support, I suspect a number of more legacy devices do not.
Additionally, the multiple bus support will allow teams to potentially increase resiliency within their robots in the case of a single bus failure.
An FD bus can be run in entirely bps 2.0B mode. So 2 busses would be great to allow many legacy devices. My concern in purely on limiting controller options because they support less than 8Mbps.
I think this is very doable, especially if a company donated part of the cost like the RoboRIO. I think the main controller could be done for a BOM cost of $150, with a lot of that going to memory, by fusing a low power FPGA with an RK3499 or similar. Add another $100 for the power distribution board and you’re not losing money on it.
