Quote:
Originally Posted by taichichuan
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.
|
Just about everything in LabVIEW is multi-threaded, beginning with the opening of individual devices. It's automatic for the programmer. It's a pretty nice environment for training students in parallelism. One of the problems LabVIEW teams ran into this year was a lack of understanding that lots of things happened at essentially the same time, and you really don't want to be using a device before it's been opened.
Getting the robot system into more student hands without the limitation of accompanying expensive cRIO hardware is a great goal. The old IFI system presented the same problem. It too was beyond the mean$ of the typical student. The saving grace there was the abundance of spares that teams eventually accumulated.
I'd also like to see the common FRC community development of a simple, inexpensive robot-based system, such as some of these suggestions, that teams can use to keep past robots operating without the expense of a replacement cRIO. The biggest problem with that is the programming environment would almost certainly change in some respects for most teams, and a LOT of teams don't have the core CS mentorship support, or often any knowledge at all of programming or electronics.
As a drop-in replacement the 2CAN isn't capable as it now stands, since it's limited to jaguar CAN control only. No PWM victors/servos, digital I/O, etc. Because of the homemade cables required, it's not plug and play. It can't support existing robots to keep them running when the cRIO is pulled off for the next year.