This year, my team (3003) used the Windows 10 Technical Preview for our main driving/programming laptop. We (happily) had few issues, other than some networking glitches.
Are any other teams using/planning on using Windows 10?
I know that many teams probably won’t upgrade because Windows 7 is very stable and there is no reason to upgrade.
Our programming mentor had issues with windows 8 on his surface, i bet he will go to 10 when it comes out. Our school seems to want to get chromeboxes for everything, but our building (the engineering/FFA part is split off from the rest of the school) still has really nice laptops, and those are probably going to keep windows 7, though we may ask to put a few to 10 just to keep them updated.
We pave our machines each year so that we have a known baseline (meaning we do a full reinstall each year), and will use either 8.1 or 10 based on whether 10 is supported.
We used Windows 8.1 this year with few problems. I like the “latest and greatest” (as the programming mentor). We’ll probably switch to 10 when it comes out.
We used 7 this year. I would have preferred 8, actually, but we used those ghastly little laptops you can get for 40 points that make you want to punch someone. We have a rather small budget.
Since Microsoft isn’t selling Windows 7 anymore… The copies of 7 in the pipeline will eventually dry up. We use 8.1 on our competition DS & 7 on the practice bot DS. Didn’t see any differences other then the 8.1 user interface being slight annoying.
I would not plan on using Windows 7 past its supported timeframe. Windows 10 will be a free upgrade for the first year, so I’d highly recommend taking that route.
SolidWorks will work fine on Windows 10 - Dassault Systems would be hard pressed to make software that did not work on their customer’s computers. Since SolidWorks sponsors FIRST, you will be given a license to the software that will work on it.
I’m curious what issues you had that make you say this?
I think it would be time for NI to make a Linux version of the driver station.
All the other development tools for Java and C++ already work in Linux, and are easier to set up and even smoother to use. I was able to download and install Java 8 JDK using apt-get in about 5 minutes and Eclipse was really just a large download and unzip. I preferred using Ubuntu for Java programming this year because it gave me no issues rapidly changing networks. It’s also much easier to connect to the robot network as well as the internet at the same time.
Linux has very robust networking capabilities, so that would mean less connection drops on the field.
Linux is very fast. My laptop takes up to 20 seconds to wake up from sleep in Windows; It takes 1-3 seconds in Ubuntu, to get to the lock screen.
Some of the most common distributions like Ubuntu are really easy to use and have most of the nitty-gritty Linux maintenance tasks automated.
The biggest plus: Linux is free it works on most typical laptops. It’ll give a good performance on many lower-end laptops and be usable.
I’d be up to making a driver station version which is completely cross platform myself if I had the RoboRIO protocol. It doesn’t seem like much of a challenge. Instead, it’s the motivation which is lacking.
It would not make sense for NI to have to run support for additional operating systems. Focusing on one basic common operating software (Windows) helps reduce software issues by eliminating the need to spread resources and cross-compile. This (FRC) isn’t a commercial product and doesn’t have the same requirements or an income stream that would lend itself to such a large cost increase. Adding one full time engineer to develop and maintain a separate branch of the driver station could cost NI $150-250k depending on what the fully-burdened cost of that employee is.
Windows as an operating system isn’t really a factor in connection issues on the field. Most connection issues are caused by robot electrical issues and improperly configured driver stations. On a properly configured laptop, Windows can boot in seconds as well (it can boot to the desktop in 20 seconds from being off).
The cost of the operating system also isn’t really a factor in the overall scheme of things.
I think the only way it would work effectively is if the driver station could only run on Linux. It would be a huge pain for the FTAs to add another large variable (operating system) into the debugging process, not to mention the cost of maintaining the separate build, like you mentioned.
On another note, though, it doesn’t seem like it would be very hard for NI to make the driver station work on Linux, because (I’m pretty sure, I haven’t had much experience with it) LabView can be compiled for Linux without many/any changes.
On the other hand, my experience is that Windows is the single biggest factor in problems switching from on-field networking to in-pit networking. There are probably things that the Driver Station can do to make it work better, but they would basically be workarounds for inconsistent and undesired Windows behavior.
I think it’s the specifics of the USB drivers that would make a Linux version of the Driver Station harder to implement than one might assume.
However, if you look at the eligibility for this program. Schools as specifically NOT included (they have different terms under their Volume pricing information for schools).