FRC Blogged - The 2015 Control System Request for Proposa

[IndySam]

FRC Blogged - The 2015 Control System Request for Proposal, the cRIO, and Beta Testing

Blog Date:
Wednesday, August 29, 2012 - 15:51
Hello Teams,

What a busy week for the blog! A few more things to share:

2015 Control System Request for Proposal

We have recently opened the search for a partner or partners to provide a control system solution for the 2015 – 2019 FRC seasons. This is not in response to the Einstein issue – we started preliminary work on this project in 2011. Also, this does not mean we are dissatisfied with National Instruments! They continue to be a wonderfully supportive partner to FRC, and we wouldn’t be what we are now without their enthusiasm, hard work, and technology. However, our current agreement with National Instrument ends with the 2014 season, and we have a responsibility to cast our net broadly as we look for a new control system for 2015 and beyond. National Instruments has been very supportive of this process, and we expect them to be one of the companies responding to the Request for Proposal, which you can find a link to here: http://www.usfirst.org/roboticsprogr...pplier-toolkit

This Request for Proposal was developed with input from our Woodie Flowers Award winners, our Control System Advisors, our Control System team, and other key volunteers. We thank them for their effort and ideas.

The cRIO

Some folks have asked, with potential changes to the robot communication system for 2013, if the cRIO itself will still be used. Yes, it will. 4-Slot and 8-Slot cRIOs will still be used for the 2013 FRC season.

Beta Testing

Deadline for applying to be a beta tester is September 7th, at Noon EST. You can learn more about the process, and how to apply, here: http://www.usfirst.org/roboticsprogr...c/blog-8-16-12

Frank

[rsisk]

Wonder if they will still be using the DLINK radios

[Steven Donow]

Originally Posted by rsisk

Wonder if they will still be using the DLINK radios

Hopefully we can at least get a higher powered radio.

EDIT: This was on the page linked by the blog:

New Radio support

FRC is constantly looking to advance the communication infrastructure used for communication between robots and their driver stations at our events. If your company is interested in partnering with FIRST to enhance this part of FRC, please contact Matt Pilotte for details.

[DominickC]

Originally Posted by stevend1994

Hopefully we can at least get a higher powered radio.

This.

[Jared Russell]

Just read through the RFP. Looks like they aren't asking for much in the way of increased functionality over the current control system (other than a USB 2.0 host on the robot controller...and I'm sure I've overlooked other small details). I think that is smart - the current system is very, very powerful.

There aren't a lot of set-in-stone requirements when it comes to user friendliness/simplicity, packaging, environmental robustness, physical connectors, etc. Let's hope that the proposers really knock it out of the park in those areas.

The other interesting thing is the projected number of FRC teams each year, which to me is comically optimistic:
2015: 3,600
2016: 4,000
2017: 4,700
2018: 5,400
2019: 6,200

Then again, I'm sure these err on the high side just to make sure a supplier can hit "worst case" volume demands.

[Nick Lawrence]

Am I the only one who misses the original Linksys gaming bridges? I find it silly that we have a radio that takes longer than the crio to boot...

-Nick

[Jon Stratis]

Reading through the RFP, I had a couple of possible concerns:

Preferred but not required support for 3D-Gyroscope and 3D-Accelerometer

Doe this mean it would be integrated into the robot controller? This would place a limitation on robot design, as the gyroscope needs to be as close to the center of rotation as possible to avoid drift.

6.8 User-Programming Language Support
The next generation RCS must support at least two programming languages (but not require that teams use both). One language must support a graphical programming environment (e.g. LabVIEW, EasyC). The current RCS supports LabVIEW, C++, and Java. It is preferred that the new RCS support as many of these currently used languages as possible. Installation and update times must be kept to a minimum for library, language updates and for software development tool installation.

In other words, we could end up with a control system that doesn't support current languages. How many teams would struggle learning a new language or interface if the one they're familiar with isn't supported?

Wireless Robot Control (WRC) modules facilitate wireless communication between the DS and the MRC over a secure network – both “at home” and at competition events. The wireless functionality may be integrated into the system or as a separate component.

How would an integrated solution work? For example, can you imagine the design challenge if the radio was integrated into the cRio? My team's design this year, with the cRio buried in the middle of the robot directly between the 4 CIM motors for the drive train, would not have been very effective.


Of course, all of these are very specific to the solution they end up going with. It's entirely possible that none of these are an issue.

[Ether]

Originally Posted by Jon Stratis

How would an integrated solution work?

external antenna?

[BigJ]

Originally Posted by Jon Stratis

In other words, we could end up with a control system that doesn't support current languages. How many teams would struggle learning a new language or interface if the one they're familiar with isn't supported?

Programming is more about the thought process and problem solving than the syntax. That being said, a controller without some sort of C-like language would probably be a very low possibility.

[techhelpbb]

Originally Posted by Jon Stratis

In other words, we could end up with a control system that doesn't support current languages. How many teams would struggle learning a new language or interface if the one they're familiar with isn't supported?

pBASIC is no longer supported. When I began as a mentor the control system was basically 2 Parallax BASICStamps. One did the communications and held it in buffer and the other was available to be customized with user programs. You had to occasionally read from the communications Stamp.

[Tom Bottiglieri]

They are also looking for 60ish laptops to support the Kinect station.

Did we already know this?

[BigJ]

Originally Posted by Tom Bottiglieri

They are also looking for 60ish laptops to support the Kinect station.

Did we already know this?

It was said (by Bill?) that we should practice our Kinect over the summer because it would be "more important" next season.

(Kinect doesn't even play video games well )

[Jon Stratis]

Originally Posted by BigJ

Programming is more about the thought process and problem solving than the syntax. That being said, a controller without some sort of C-like language would probably be a very low possibility.

While this is true (I've been programming longer than any student on my team has been alive, so I'm very familiar with process vs syntax, and have probably forgotten more languages than any student on my team actually knows), the syntax is usually a major hurdle for beginner programmers. There are also some significant structural differences between many languages that can provide serious problems for students if they try to switch. What if you're used to Call by Reference being the default in one language, then switch over to Call by Value in another? Someone who has only had a year or two of limited experience with one language would have trouble switching their thoughts over to the new paradigm.

[AllenGregoryIV]

A couple interesting requests for the new controller that I noticed

MRC7. USB 2.0 host port
MRC10.Onboard non-volatile storage sufficient for storing user code and logging data (up to 3 event-days) with no perceptible performance issues by the user
MRC11.Ability for user to remove storage is preferred, but not required
MRC14.A display providing basic diagnostics is preferred, but not required.

Examples of such diagnostics include, but are not limited to:
a) team number,
b) IP address; Page 14 of 23
c) Link status
d) Enable disable state
e) Teleoperated/autonomous state
f) Common error codes

Those would all be nice improvements to our current robot controller.

[techhelpbb]

Originally Posted by AllenGregoryIV

A couple interesting requests for the new controller that I noticed

...

Those would all be nice improvements to our current robot controller.

The current cRIO does have user accessible flash memory.

The current cRIO can send all that information via visual means connected to GPIO or I2C on the robot even when disabled.
Someone would just have to make something to do it. Display devices could easily include: LEDs, a backlit LCD, light bulbs, low voltage electro-florescent displays.

There is no USB 2.0 Host support on the cRIO but you could put a COTS device on the robot like a laptop. However, I'm not sure that part is really a slam dunk. USB has 3 common modes: Human Interface Device (HID), mass storage, and CDC (serial communications). Each mode is rather complicated. Generally when you plug devices into a host port there needs to be a driver for that device. No driver means no support. So even if you could make a USB 2.0 Host port you'd need software support in the control system to make it work with devices. That's *a whole lot of devices*. Usually things that don't run Windows/Linux/BSD/Mac OSX have to be selective about the USB hardware that actually works. After all what's the benefit to the device manufacturer to make drivers for your unusual low sale volume platform (<10,000 teams...Microsoft can give that away and basically did with the Kinectx).