View Single Post
  #154   Spotlight this post!  
Unread 15-08-2013, 17:16
Chris is me's Avatar
Chris is me Chris is me is offline
no bag, vex only, final destination
AKA: Pinecone
FRC #0228 (GUS Robotics); FRC #2170 (Titanium Tomahawks)
Team Role: Mentor
 
Join Date: Dec 2008
Rookie Year: 2006
Location: Glastonbury, CT
Posts: 7,718
Chris is me has a reputation beyond reputeChris is me has a reputation beyond reputeChris is me has a reputation beyond reputeChris is me has a reputation beyond reputeChris is me has a reputation beyond reputeChris is me has a reputation beyond reputeChris is me has a reputation beyond reputeChris is me has a reputation beyond reputeChris is me has a reputation beyond reputeChris is me has a reputation beyond reputeChris is me has a reputation beyond repute
Send a message via AIM to Chris is me
Re: NI Week Athena Announcement and Q&A Panel

Quote:
Originally Posted by magnets View Post
While I do agree that the vex cortex is probably closer to an optimal controller than the cRIO was, it is not a replacement for the cRIO/roboRIO.
The vex controller can't do image processing, it can't be programmed in LV or java, and it doesn't have an ethernet port or a CAN port. It also doesn't have an FPGA. While it may be a substitute for 99% of FRC robot controllers, there are definitely teams who do need the extra stuff.
If the choice was, hypothetically, between "have image processing offboard" and "take a really long time to boot and connect", I think nearly everyone would be in favor of the former option. I'm not saying the Cortex as is would be the perfect FRC controller, but I think making fast processing an optional feature you add on via an offboard PC (something teams already do) would allow the "base" control system to be simpler / faster / more robust / quicker.

The frustrating thing to me about adapting existing technology to FRC is that FRC has some specific requirements that are unusually important that aren't present in a lot of commercial applications. In the (admittedly very few) conversations with NI people I have had in the past, it seems they consistently underestimate the importance of quick boot time. It just doesn't seem to be a high priority in the controller design or implementation. Perhaps FIRST should have emphasized the importance of speedy boot time and quick field connections when doing their RfP for the control system.

All of the cool software things you can do with a more powerful controller are automatically far less important in my mind than making sure that the robots connect to the field in a reasonable time frame and that they never disconnect. Just my relatively uninformed two cents.

(None of this post is intended to discredit the hard work NI and its employees have put into this program. It's just some thoughts - I apologize if I step on some toes)
__________________
Mentor / Drive Coach: 228 (2016-?)
...2016 Waterbury SFs (with 3314, 3719), RIDE #2 Seed / Winners (with 1058, 6153), Carver QFs (with 503, 359, 4607)
Mentor / Consultant Person: 2170 (2017-?)
---
College Mentor: 2791 (2010-2015)
...2015 TVR Motorola Quality, FLR GM Industrial Design
...2014 FLR Motorola Quality / SFs (with 341, 4930)
...2013 BAE Motorola Quality, WPI Regional #1 Seed / Delphi Excellence in Engineering / Finalists (with 20, 3182)
...2012 BAE Imagery / Finalists (with 1519, 885), CT Xerox Creativity / SFs (with 2168, 118)
Student: 1714 (2009) - 2009 Minnesota 10,000 Lakes Regional Winners (with 2826, 2470)
2791 Build Season Photo Gallery - Look here for mechanism photos My Robotics Blog (Updated April 11 2014)

Last edited by Chris is me : 15-08-2013 at 17:20.
Reply With Quote