LabVIEW Runtime for Linux

[AlexBrinister]

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

[Greg McKaskle]

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

[AlexBrinister]

Could we not then use Driver Station in Linux? So that we wouldn't have to use Windows for anything?

Alex Brinister

[Alan Anderson]

The Driver Station application is a Windows executable. It's not compiled to run under anything else.

[AlexBrinister]

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

[Greg McKaskle]

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

[Fifthparallel]

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.

[Greg McKaskle]

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

[Fifthparallel]

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

[Greg McKaskle]

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

[Alan Anderson]

Originally Posted by Fifthparallel

What are some good examples of windows specific libraries the driver station uses?

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.

[Fifthparallel]

Thanks for the explanation! It all makes a lot more sense now.

[Japper]

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

[jhersh]

Originally Posted by Japper

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.

[Fifthparallel]

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?