[The Lucas]

Originally Posted by tdlrali

It's now called "Driver's station" (probably due to trademark issues), and has similar features as the IFI OI - disable/enable/autonomous, 8 digital and 8 analog inputs, 8 digital outputs, 4 USB ports, a small LCD screen, and two ethernet ports (one to robot, one to optional laptop for dashboard)
No, tethering will just use a normal ethernet cable. You will most likely have to turn off the robot-side access point in the pits.

I think you will need a crossover cable to tether, not a normal Ethernet cable. People haven't been talking much about the Driver's Station. This is the new (in development) custom electronics part of the control system. Along with that there is new Field Management System. The cRIO on the other hand is a battle tested industrial controller. If/when there are technical issues with the field (there always are), it is likely most problems will be with the new Driver's Station and Field system, not the cRIO. Also, if I understand the answers to my mentor session questions correctly (I sat in the back and asked a few auto/disable questions), the driver's station will handle more of the on-field control than the old OI. The old OI plugged into the Field Controller through the competition port and most of the work was done by the field controller. The new Field system will be simple/cheaper, and more of the work will be done by the Driver's Station.

Originally Posted by Greg McKaskle

The FPGA on the cRIO is an open LV target. This means that LV code can be designated to run on the host PC, the PPC, or the FPGA. Of course LV targets the FPGA via VHDL, and therefore the cRIO is ultimately targetable with C-based .out PPC files and bitfile produced from VHDL. To promote a migration path, promote working, stable robots, and ensure safety, the decision was to keep the FPGA closed for at least the first year. After that, depending on how things go, it could be opened to the extent that there are vanilla, chocolate, and rocky road flavors. It could be opened further by providing 09 source and allowing teams to go nuts. Technically, these are all possibilities, and it is a policy decision as to what makes the most sense for the organization and competition. At this point, I'm sure FIRST is listening, but any opinions you may have honestly aren't well founded. After a season, the feedback will carry much more weight.

I have been wondering exactly how FIRST will implement disable/auto control since I saw the system (that was the root of my question at the mentor session). I understand that FIRST would decide to close the FPGA for safety and other reasons. I think it would be possible to allow teams to customize small portions of the FPGA code and still maintain safety. Based on looking at the Digital Sidecar , I speculate (no facts) it is already decided that one (perhaps both) NI 9403 Digital I/O Modules will be configured (in FPGA) to provide 10 PWM out, 8 relay out, 14 GPIO, SPI and these cannot be customized. I (and most people here) are not so concerned with changing the number of PWMs provided, but are very interested in customizing those 14 GPIO pins.

I think it should be possible to customize the 14 GPIO (and the NI 9201Analog Input Modules) without sacrificing safety, since those pins should not be controlling motors (PWM and Relay) or pneumatics (NI 9472 Digital Output Module). The disable logic on the PWM, Relay and soleniod should not be affected by changes to the GPIO and analog inputs. Perhaps, teams could write small VIs with the appropriate of Inputs and Outputs for the GPIO that could be automatically inserted into the main FPGA Code. Maybe there could be a custom FPGA loader tool where you simple input 4 VIs (2 GPIO, 2 analog inputs) and the tool inserts these into the appropriate parts of the (hidden) master FPGA source and generates/loads the netlist. I haven't used LabVIEW too much, would it be possible to customize small portions of the FPGA code while keeping the rest of the source hidden from teams? If this is not possible, could there be a simple custom GUI where teams select their sensor types and pins, and downloads the correct netlist to the FPGA?

Originally Posted by Billfred

8) Perhaps a stretch, but what about a no-autonomous switch on the robot? I can think of at least one case this season where such a switch on the robot would've spared a team a yellow card. (The team ran their autonomous, which hit the far wall a little hard and forced a match restart. Since they couldn't reprogram their autonomous in the time given, they went right ahead and clocked the wall again. Yellowcardsville.)

A no-autonomous switch could be easily done this year (well easier than writing most auto routines) and I imagine it would be easy to do next year as well if you want one. I don't want something on the controller that some can accidentally flip and disable autonomous for that match. However, I would love an Auto-only E-Stop for the drivers. No matter how good your auto routine is; things go wrong, collisions happen, sensors fail, etc. It would be nice (and safer) if the drivers could kill an autonomous gone wrong without the consequence of being disabled for the rest of the match.

Originally Posted by Greg McKaskle

Personally, I'd find it much more useful if some of this energy were directed into a technical wish-list. Then both FIRST and the staff working on the project could measure the current 09 project against various expectations.

I'll try to organize some of these thoughts into a proper list for the other thread.

[Side Rant] Why are people giving Greg McKaskle negative reputation? That is a really weird way to to say "Welcome to Chief Delphi Forums, thanks for your insight into the 09 Control System". I know they are just dots, but I suggest everyone reread the reputation FAQ for the reasons to give negative rep. Some his replies may be a little blunt, but he is positively contributing to the discussion, so be civil.

I understand some people here do not like the changes in FRC or FTC control systems, but don't shoot the messenger. Furthermore, don't shoot an engineer of your new control system who takes the time to answer our questions in this forum. We want people like Greg to become part of our community as he has in other forums. He certainly has contributed quite a bit already, lets make him feel welcome. [/Side Rant]

Wow that was long, can you tell I was catching up on work this week