Re: LabVIEW Runtime for Linux
 

The DS is a trusted element of the field and the robot control system and it is responsible for some portion of safe robot operation.

Putting the DS on other OSes, supporting proprietary controllers, and other enhancements are fine ideas, and the Kinect integration is an example of how FIRST has enhanced the DS. But these cannot interfere with the primary responsibility of the DS.

Perhaps it would be useful to break this discussion into smaller requests and consider them independently and see if something comes out that is simpler and easier to validate than the original topic.

Which is the bigger request, MacOS, linux, rumble, analog triggers on XBox360, or ???

Doing all of these while maintaining safety is asking for quite a lot. Simply testing the combinations would take quite a bit of effort.

Greg McKaskle

Re: LabVIEW Runtime for Linux
 

Xinput controller support in the Driver Station

Most usb controllers are: HID for use with DirectInput (like the Logitech Attack3 Joystick), XInput devices meant to interact with XInput (like most modern game controllers, and the Xbox360 controller), or hybrid controllers with a hardware button that switches between the two modes.

So while it was all rather muddled, I asked if it was possible for the Driver Station to have a button in the Setup tab that switched in between using either XInput or DirectInput, which would give most controllers their expected functionality (in the case of the Xbox360 controller and others), but also open up the spectrum of devices teams are allowed to use. I also asked if DirectInput was kept as the sole controller input scheme because of devices like the Attack3 joystick, which is a HID (DirectInput) device.

How It Relates To Multiple OS support


One of the barriers to porting the DS per your earlier explanation was the use of DirectInput in the Driver Station on Windows.

DirectInput was phased out in 2005 by Microsoft in favor of X Input. X Input can be found across all distributions (man pages are available for both OSX and Linux), while DirectInput by default is not there. Given that one of the reasons the DS is not portable was the fact that it relies solely on DirectInput, then adding X Input support in the DS would let us use controllers with the DS on either OSX or Linux.

This may account for your broken arrow & joystick problem (the light was green with no joystick plugged in, right?), as DirectInput is not by default a part of OSX. However, HID Manager and a Leopard API exist for OSX which can effectively replace DirectInput on the Mac.

Regarding some of the other cross-OS problems, detecting network interfaces on OSX and Linux and then setting their ip addresses is very easy. Try typing ifconfig in your shell on your Mac sometime.

Re: LabVIEW Runtime for Linux
 

Can you try "ipconfig set robot-protocol AUTOMATIC 10.te.am.02 -safely"? Let me know if that is works?

Greg McKaskle

Re: LabVIEW Runtime for Linux
 

There is ipconfig for OSX, but I do not have anything running OSX handy. ipconfig does not ship with most GNU/Linux distributions, while ifconfig is the unix tool that ships.

However, treating that as a one line command is not valid, even in the Windows 7 Pro 32-bit VM I'm using.

Could you clarify what that command you posted is supposed to do?
Is "ipconfig set robot-protocol AUTOMATIC 10.te.am.02 -safely"

running ipconfig
setting a system variable robot-protocol as AUTOMATIC
setting the ip address to 10.14.10.2 (?) with ipconfig, then adding a -safely flag to it?

(while this might work on the cRio (if that's where you got it from), the cRio implementation differs vastly, as the options you listed do not appear to exist. Some of the options appeared in a search through MSDN, but did not resolve.)

A Solution?

type
This (using sudo, which gives the command Admin privileges), calls ifconfig, which then access the device/interface en0 (the ethernet port on your Mac), gives it the ip address 192.168.0.255, and sets its subnet mask to 255.255.255.0 .

An Aside

I'm happy to give an explanation of how I would have the DS handle it, although I do not know if there is a specific method needed to handle it. However, I'm becoming more curious about how the DS works and would probably be fine with a Linux port being considered a wontfix. Realistically, a lot of things (like setting the proper ip address) would need to (or should) be done by teams themselves.

Given that most teams do not use a Cypress, a lot of teams are not using the Kinect, and XInput is an easily rectified barrier to porting, I think that the people who are asking for a Linux port want one to take advantage of the very "no frills" approach, faster boot times, interesting (and in some's opinion, better) driver support handling (with the exception of wireless), battery savings and so on, in addition to the performance changes experienced which reduce battery consumption or lag (perfect for Driver Station laptops.)

Imho, then, it appears that the teams should have the choice to use the port, but should be aware of the fact that it will be a "stripped down" version of the DS, field personnel cannot (or will not) support it, and that things may not work so it will be up to them to troubleshoot. While I understand that FRC is supposed to create ease of access to technology, making it streamlined and easy for teams, those who want to scale the barrier via rock climbing and know they can do it should be allowed to do so.

Re: LabVIEW Runtime for Linux
 

Sorry, that was my attempt at humor -- not very successful in hindsight.

The porting of the DS to other OSes is not limited solely by my ability to read man pages. The DS OS was selected to allow the largest number of teams with varying backgrounds to participate safely in a FIRST experience. In the future, that could mean a different OS choice or choices, but for the time being, the reasons for porting it do not seem to justify the work and testing required.

The support of XInput devices is something that was considered, but was not made a requirement. In my opinion, subsetting the functionality of the DS for various OSes would cause a large amount of confusion. FIRST typically has one or two revisions they will allow on the field to aid in running an event more smoothly. They do not even want to use DSes from previous years, even if the protocol implementations are identical.

Greg McKaskle



Greg McKaskle

Re: LabVIEW Runtime for Linux
 

I think that the FIRST community could provide a lot of help to making this a reality. Asking a few people to port a complicated piece of software in a limited time with a bunch of restrictions and considerations is a bit much. I think making the source of DS available to FIRST teams would be a step in the right direction.

Alex Brinister

Re: LabVIEW Runtime for Linux
 

This sounds familiar. Sounds like we are back to making a request to FIRST.

Greg McKaskle

Re: LabVIEW Runtime for Linux
 

My Programming captain is developing a driver station using Java mostly for being able to work on Linux. You can find it here.
https://github.com/anidev/frc-driverstation

I talked to my programming captain and as of 1/6/13 the Java driver station is capable of enabling, disabling and selecting different modes (auto tele and test), but not capable of actually driving the robot.