Quote:
Originally Posted by Alan Anderson
LabVIEW is not required, and you don't need to use the default Dashboard as a starting point. The robot can be running a program written in any language, and so can the computer hosting the rumble-capable controller.
Minimal UDP communication from cRIO to computer is simple, but if you don't want to roll your own, there are well-supported implementations of Network Tables (and thus Smart Dashboard variables) for LabVIEW, C++ and Java.
|
Thanks for wording this clearer than what I was trying to do in my initial post... the confusion for me was... where the labview code was being applied.. I thought it was part of the robot code, but now I know it is a part of the custom dashboard.
When I was talking about doing this "(e.g. make a wedge proxy to the dashboard with its own networking solution). " I was hinting toward
this solution. This wedges a proxy by being the main app that uses ShellExecute() to launch the SmartDashboar.jar. This way I can make my own code while still having full use of the Java client. In this project the compositor plugin has its own direct input implementation that runs parallel to the driver station's use of direct input. So yeah I could, and most likely will flip over to xinput. I'll want to use the same platform as the driver station for the sake of integrity... I know one day they'll switch and it may be next year.
On that note... they may indeed have full HID support and if so then all of this method will no longer be needed to gain full access of joystick support, but I'd still need it for the compositor. There is no confirmation on that, but I know it is a possibility as I've requested for it to do things like acquiring the joystick's name on any slot, and POV axis support etc... during beta.
Thanks for saying "well-supported" as the description of Network Tables.
