Hi Gang,
I've had good luck with this:
http://www.phidgets.com/products.php?product_id=1018
It's a USB-based device with 8 Digital in, 8 Digital out and 8 Analog in. It hooks up to shaft encoders and a whole raft of sensors. All of this via USB. I feel that the USB approach may have some merit because of the simplicity of the cables and the ability to buy them off the shelf if you don't already have a bucketload of them around the house. And, they've got libraries for all of it (open source) for Windows, Linux, and OS/X. We could probably port them to VxWorks and the WPILib approach easily enough. For most of the sensors, the USB cabling should be more than sufficient for the power draw.
As to using the laptop for most of the processing, I'd be concerned for the control lag that we saw on the field using the wireless. If anything, I'd be more interested in making the robot more, not less, autonomous. The 400 MHz PPC in the cRIO has way more than enough CPU and RAM for our purposes. The problem is the linear nature of the robot code that's running on the target CPU. Most teams weren't trying to use any multi-threading (does Labview even support this concept? It must, but I'm not sure) and were simply polling everything in the teleop control loop. This approach makes the CPU look to be 100% busy and provides poor performance all the way around.
Also, there were a *lot* of problems with the off the shelf video processing code. I seem to remember at least 3 copies of the image before we got an answer on what the camera was looking at. IMHO, that's just poor coding. But, it's also something that's easily fixed.
So, I don't think that it's the speed of the CPU that's the problem. It's the programming model that doesn't effectively use the resources that were supplied. There should be threads that look at the sensors and use decoupling mechanisms like message queues for communications. These things should be blocked most of the time and not burning any CPU time when they're not needed -- rather than being in the main teleop loop.
As for one of the earlier posts regarding the use of DKMs, I tend to agree. The flat address model in VxWorks if fraught with land mines if you're not careful. VxWorks does support a user-mode executable "real-time process". But, the WPILib would need to be built to be used in that kind of model before RTPs could become commonplace.
A shared library in Linux's protected memory model would certainly be "safer" IMHO because it would catch both NULL pointers and stack overflows -- the two most common errors in VxWorks development among the folks who use it for "real" applications.
Mike