Quote:
Originally Posted by Gdeaver
I'll throw this out there. It has already been noted that with the 2can box a basic drive train only robot can be created. Why not serialize the whole thing and take the heavy duty expensive brain and FPGA out of the robot? Isn't this the strategy Microsoft was pushing with the robotics studio environment? In other words, we would use a laptop with what ever power a team felt necessary as the main brain. The lap top would take user input through the USB ports,and do all of the processing. Command and status packets would be transmitted over wifi as we have now. The 2can can be expanded and maybe have a pair of can ports and some usb. There are usb servo boards with 20 pwm on them. Next add a usb or can solenoid driver board, a digital io board and an analog board. Other than maybe having problems with zillion cpr encoders, everything that we have now is there. In other words get everything back to a PC and do the crunching there. Now you have an Intel/AMD/Nvida platform to host the operating system and do the processing. The cost of the individual boards would be well under 200$. The cost of the 2can would go up . There are companies providing boards like this for the Microsoft robotics studio and .net frame work already.
|
I think the ability to run code directly on the robot is a very important resource to have. I'm sure many of you who have been on the field (and the programmers too) have experienced the "control lag" that occurs when a robot begins sending an unusual amount of data over the network (major robot problems usually go with this). Now, instead of the controls taking that long to get there, imagine it's sensor values running back to a computer. Autonomous calculations would slow down immensely since all I/O is now running over a wi-fi network being shared with 5 other robots who could have major problems. The current FRC packet spec is a very light network footprint (apparently it's smaller than the minimum wi-fi packet), leaving only unusual situations in the laggy conditions.
Also, think about what HAS to be on the robot side. The system watchdog has to be on the robot (even more important because of the above paragraph), the NetworkCommunication library has to be running there, I/O interfaces have to be running. It just turns the 2CAN into a mini-cRIO that you aren't allowed to program. Much less power there.
And then think of all the problems you can run into with using a regular laptop to run the robot code. Under normal conditions, the only time a cRIO is on a shared network is when its on the field, where network security is locked down tight. But a laptop, on the other hand, is quite likely to be connected to the public Wi-Fi at an event (especially the programming laptop, which this would become). Now imagine a virus making its way onto a team's competition laptop. Now almost every single team at the competion has a virus. I remember from philly(?) that one of the inspection USB drives got a virus on it and spread to a few classmate computers. This virus prevented them from connecting to the field properly. It's a real problem
__________________

"To have no errors would be life without meaning. No strugle, no joy"
"A network is only as strong as it's weakest linksys"