Driverstation in Linux

[pavanetti]

I use Linux and NetBeans to programming the robot in Java. I want to control the robot in my linux laptop using the driverstation. The driverstation is writing in Labview, but we can't access his code. Did anyone control the robot in Linux?

[Wing]

I've heard of a few fellow programmers attempting to create an application to do so, but I haven't seen any success so far. Also, i'm pretty sure FMS only sees windows computers with the driver station software, or atleast that's how it was in 2011. I'm not an expert in the communication between FMS and the dashboard, but in 11, you had to have a certain account name and info to be able to access your robot in competition.

[Slix]

I think there was an experimental driver station here:

https://github.com/robotpy/robotpy/tree/2012/sim

I have no idea whether it works though.

EDIT: Or maybe it wasn't there. I think it was somewhere in RobotPy or one of its contributor's Github repos.

[linuxboy]

There may be one out there, if I have time this summer I might try to write one, but the only Driver Station prom that can be used in competition is the LabView one supplied by FIRST, even if someone manages to write a different Driver Station that is compatible with both the DS-Robot protocol and the FMS-DS protocol it shouldn't be used at a competition.

[Greg McKaskle]

Some of the DS protocols have been reverse engineered and unofficial ones have been used in off-season situations. If you look around, I'm sure that you can find some of the info. Or you can use wireshark and work your way through it.

But, remember that the DS is a key safety element. If it were to fail to disable or estop a robot, or were to slip into tele or auto at the wrong moment, the robot WILL respond. The cRIO implements a watchdog to shutdown if the DS disappears, but if the DS is there, it is trusted, and that means that the DS is largely responsible for the state of the robot.

For the record, the field doesn't know or care what OS or language the DS is running on. Both Windows and linux were considered. Windows was selected primarily to simplify the admin duties -- no flames please, I know it isn't that difficult with linux and isn't simple with Windows. I suppose ideally, the DS would be available for everyone's chosen OS. The DS was/is currently written in LV, and LV exists for all of the major laptop OSes, but the level of testing and integration for things like detecting joystick insertion/removal, and supporting the FirstTouch board make it pretty time consuming to add another OS. Even Windows 8 will obviously require lots of hand testing to validate the safety and networking requirements. Additionally, the FTAs and CSAs who try to efficiently resolve connectivity and versioning issues would now need to be aware of many additional OS factors. In the end, it is an arbitrary decision necessary to simplify the logistics.

Greg McKaskle

[Mark McLeod]

The custom blue box Driver Station first used with the cRIO system in 2009 was a Linux implementation.

[TEAM1100soft506]

My team has looked into this as well. we have a network in our lab set up so that we send code from our linux box to the windows box running the driver station that then runs the robot. as of right now this is the best solution that we have found.

[ratdude747]

Originally Posted by Mark McLeod

The custom blue box Driver Station first used with the cRIO system in 2009 was a Linux implementation.

...and that was the only thing that seemingly worked right... In the world of unreliable FIRST hardware, the only devices that were about as unreliable as the Blue boxes of doom are the 2008 IR boards of doom... only with the IR boards you usually knew when yours was fried (blue smoke); the Blue boxes were random. IIRC a poorly grounded field ruined half of the boxes at the 2009 FiM Champs. Even if you did ground the boxes right, they still liked to fail. The complete and udder failure of the boxes is why we have the laptop/netbook based driver stations we have today.