Why doesn’t National Instruments put a copy of the LabVIEW runtime for Linux in the Kit of Parts? If they did, our team would be able to use Linux 100% for coding. Is there any way to request this? Coding in Linux would eliminate all the countless problems that arise while using Windows… like random blue screens while writing code in Wind River…
Alex Brinister
Can you explain more about what you’d do with this? How does a LabVIEW runtime help with blue screens in WindRiver? The LabVIEW runtime for linux is a free download, but I’m not sure I see the connection.
Greg McKaskle
Could we not then use Driver Station in Linux? So that we wouldn’t have to use Windows for anything?
Alex Brinister
The Driver Station application is a Windows executable. It’s not compiled to run under anything else.
Is there some way to request a Linux executable? Or at least ask FIRST to give us source code so we can do it ourselves?
Alex Brinister
You can certainly request it, but at the end of the day, the testing and support effort is reasonably high.
I’d love to create the DS for a mac, like I’m using now, Windows, like I have in my VM, and Linux, because penguins are cute ; ).
The LV code is the same, but the calls to read joystick, detect a disconnect, locate special keys, communicate to the Cypress, not to mention detecting radio configuration and updating it are not platform independent. Those are the elements that have risk. We will see what the future holds.
Greg McKaskle
Why not use something like Python + GTK to create something portable/interoperable for the DS? FWIW, the FMS and general robot code are all made of interfaces which should allow anything to interact with it/receive information from it, right? The LV development suite & robot code can’t really be helped, of course, but our driver station laptop isn’t needed for development and would like a penguin sticker on it.
The DS could be written in many languages and run on many OSes. But that doesn’t mean it will be quick to develop. A basic DS, sure, but one with all the I/O support and logging will be quite a bit of effort.
LV applications are quite portable, by the way, but not necessarily the DLLs or OS specific libraries they call. I attached it loaded on the Mac, notice the broken arrow? That is where the effort would come in, and in addition, you would then need to make sure that support folks at the events would know how to troubleshoot and setup networking and the like on linux, mac, and windows. This is where the real effort comes from.
Greg McKaskle
What are some good examples of windows specific libraries the driver station uses? Sorry for the mistake, it seemed like the issue was not being able to port the DS because of the differences in the various Runtime engines.
Besides that, what are the additional use cases of the Driver Station aside from a driver driving the robot or diagnostics? Would I be able to answer my own question by looking at the driver station project?
Thanks
OS stuff include the DirectInput stuff to read the joysticks, detect a disconnect, and at one point it needed to locate the estop button.
The calls to read, configure, and deal with the Cypress.
There are a number of calls to locate NICs, identify whether their setup makes sense given the team number, and potentially even reconfiguring them.
There was a call to identify when the laptop was reawakened from sleep.
The Kinect stuff was pushed to a server, but that would be an issue if not using Windows.
The other stuff that the DS does is to fire up 12 separate loops speaking unique protocols to FMS, robot, Kinect, Cypress, Dashboard, keyboard, joystick. Then it logs and charts the stuff and tries not to use much CPU.
A number of folks have written their own DS mimic’ing the basic protocol to and from the robot. As long as you keep safety in mind, it is a good project to take on. Just be sure to test all the things that would cause an out of control robot.
Greg McKaskle
Greg already gave a reasonably comprehensive answer to that question.
Besides that, what are the additional use cases of the Driver Station aside from a driver driving the robot or diagnostics? Would I be able to answer my own question by looking at the driver station project?
I think controlling an FRC robot is the only thing the Driver Station is meant to do.
The Driver Station project is not published for people to look at.
Thanks for the explanation! It all makes a lot more sense now.
Is it even possible to run the FRC version of Labview on a Linux system?
I would like to be able to put together a Labview application for use in the pit to run on a Raspberry Pi running linux and am wondering what it would take to do this if it is even possible…
thanks
The Raspberry Pi is an ARM processor. The LabVIEW for Linux is compiled for and runs on x86 Linux.
You could potentially write an application using LabVIEW for ARM, but that is a much more hardware-centric version of LabVIEW and is not terribly easy to use.
Out of curiosity, is DirectInput only used instead of XInput to provide support for legacy controllers like the Attack 3 joystick? It’s unrelated, but can we have a choice of using either DirectInput or XInput? Being able to use the two triggers for tank drive would be appreciated.
More related, though, if I read the post earlier correctly then DirectInput, getting system calls for laptop going to sleep, and Kinect server stuff were the meat of OS-specific parts of the Driver Station. Xinput, the successor to DirectInput, has already been ported to both OSX and has a man page entry for Linux-kernel distributions. OSX has power assertions instead of sleep mode system calls, and “sleep” is taken care of in userland by things like the X window system on various linux distros. Kinect server stuff doesn’t look like it can be helped, although youtube presents people using the kinect images on both OSX and Ubuntu 9.04 and up.
Is there anything that can be done about this?
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
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.
Can you try “ipconfig set robot-protocol AUTOMATIC 10.te.am.02 -safely”? Let me know if that is works?
Greg McKaskle
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
$ sudo ifconfig en0 192.168.0.255 netmask 255.255.255.0
>Enter your password here (assuming you're using an account with Admin privileges. Ifconfig needs admin privileges to make system changes.)
$ ifconfig
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.
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