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/roboticsprograms/frc/frc-kit-parts-supplier-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.
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.
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.
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.
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.
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.
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.
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.
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).
Ought to be interesting to see if IFI is interested in once again being our control system supplier.
I’m sure many FRC mentors would rejoice at that concept. Sadly, I have a feeling that wont happen, either because IFI isn’t interested anymore, or because FIRST might categorically reject a proposal from them. The old IFI systems were much faster to boot than even the 2009 cRIO-based system, which was the best one yet.
I also wonder if FIRST will be transparent with the FRC community about who is proposing?
I really can’t see them being transparent in the process. I can’t imagine the “you know what storm” that might erupt when a few thousand FIRST volunteer engineers each with their own pet companies and ideas debating this on CD.
Think Mac vs. Windows debate to the 10th power!
Things like this must be done with a limited committee of dedicated individuals.
We still use ours for practice robots.
Even after a robot landed on it in 2010 and dented the case.
On topic, I am interested to see the possible solutions. I hope all of the developers will focus on simplicity before optional features, as I would much rather have a simpler system that always works than something even more complicated than what we have now that also has a USB2 port. That said, I would love more features if they are reliable and don’t cost too much in terms of weight/complexity, especially if they’re optional - such as a smart PD board that can optionally be connected to a CAN/LIN bus or left unconnected.
I also wish FIRST would give up on processing vision on the RC itself. Dashboard is fine, coprocessor is fine, just not the RC itself. It’s already busy.
They did not say they where changing just the contract was up, and doing they are doing due diligence. NI does not depend on making money from us to stay in business. I imagine a smaller company like IFI would. If not NI I would expect First would want another company with similar resources take up the challenge.
For reference look up a single seat license for the pro version of labview costs.
What bridge or other wireless solution gets used is a totally separate subject from the robot controller.
)