With the shift to the new control system, we were wondering what programming language teams were going to use. In the past we have programmed in JAVA, as the student body had experience in that. We were wondering if the introduction of the new control system would mean Labview would be the most supported language, and whether that would warrant a switch. We are leaning towards Python at the moment. How did your team choose the language, and why?
I wouldn’t imagine the new control system would prompt teams to switch, unless something comes out indicating an issue with one of the main three languages.
Our team did Python the first two years and are now switching to Java mainly for ease of use and the ability to compile in a nice IDE. Disclaimer, I didn’t actually work on programming this past year, I’m just relaying what I remember hearing from them. So take this with a grain of salt.
We ran into a lot of annoying syntax errors that would have been caught instantly by Eclipse and would have prevented us from loading obviously bad code onto the robot. We also had issues with the routing tables at competition. I’m not sure of the exact issue, just that our programmers firmly believed that debugging the issue would have been straight forward in one of the main three languages, but in Python it was challenging. Also, the community for using Python in FRC is much smaller than the big three and it can much more difficult to get help on weird issues. That isn’t a huge limiting factor though, because the MPI interface for Python is very similar to the C++.
Again, this isn’t first hand knowledge, but I recommend you look into other teams’ experiences before committing to the switch.
I would expect that support for the ‘big three’ languages would remain the same as it has been.
Our team did Python the first two years and are now switching to Java mainly for ease of use and the ability to compile in a nice IDE. Disclaimer, I didn’t actually work on programming this past year, I’m just relaying what I remember hearing from them. So take this with a grain of salt.
We ran into a lot of annoying syntax errors that would have been caught instantly by Eclipse and would have prevented us from loading obviously bad code onto the robot.
This is one of the problems with using python – since it’s dynamically typed, you have to actually test/run your code to find the syntax errors, as opposed to depending on a compiler. To help with this, one thing we introduced in the middle of the season was a robot simulator that allowed you to run your code on your laptop, which my students found quite useful for quick iterative development. Python development for 2015 is pretty active, so hopefully the community will grow more this year. 
Hello, I am a programmer for Team 900. We are one of the beta Teams for the 2015 control system. My team uses Labview, and we have found that the language works the best. Most of the errors on the beta forums seem to be about C and Java. We have found that labview is powerful, has the most community support, and is extremly easy to teach to new students, although from your post it seems that many of your students have a background in Java. Our team used Java during my freshman year, and we had many difficulties. Labview is easier to debug and spot errors, expecially because you don’t have to worry as much about syntax. Java is also not particularly optimized for the realtime enviornment of the RoboRIO. If you can, I would highly suggest switching to labview. C has less problems than Java, and can be useful for some lower-level stuff, but still has the same problem of being difficult to teach to new students. I wouldn’t recommend programming in anything other than the above three languages, because after that support from both the community and from FRC is extremly low.
If you have any questions about the new hardware, feel free to contact us at the email [email protected]. We are right next door to you in Durham, NC, and gave a presentation about the hardware at THOR. We will also be giving a presentation at Chapel Hill High School in December.
Edit: Something that I have overheard other teams saying multiple times is that they don’t want to use a “Kiddy” graphical language, equating labview to something like scratch. Labview is a powerful industry tool designed for control systems, and that is what a robot is: a control system. One of our mentors works for Cree (LED Light Bulbs) and labview is used in their systems.
I haven’t been following the beta forums very closely, but are the issues actually with how the Java or C executable run on the RoboRio? Or are they more related to learning or adapting to new things in the language or MPI? I would assume it was the later.
If you can, I would highly suggest switching to labview. C has less problems than Java, and can be useful for some lower-level stuff, but still has the same problem of being difficult to teach to new students.
Some would call this difficulty a positive. A lot of teams prioritize education over ease of teaching and we chose to use a written language in order to provide our students with the skills to adapt to various other written languages. Labview is great for robotics applications, but we have been scared away from it a bit, haha.
All three languages will be fully supported. The beta forums shouldn’t really cause concern. They highlight just how many details have to be managed in order for a language to run on a controller. Java is undergoing the largest amount of change, but it will get there.
As for picking a language, all three languages have something unique to offer. What is most important is that your team learns how to use whatever language you choose to best measure and control the mechanisms on your robot. WPILib was written for all three languages in order to give them common ground. The language syntax and some structure will differ, but hopefully this allows teams to experiment, help each other, and learn something about each of the languages.
Greg McKaskle
It’s really nice that we’re switching to Linux now! The Linux-specific C++ libraries are extremely powerful, and come bundled with a ton of really cool features.
The library, DLib will also work on Linux, as there are some dependencies that should be available such as PTHread.
Other than that, does anyone know wherher C++0x/11/14 will be supported? I would love to use some of the features such as auto, std::thread and std::async!
Java has been great so far, just a few hiccups here and there, but nothing that would prevent you from using it, and almost all the problems should be ironed out before you have to use it.
I don’t remember where I read it, but I think that C++ is able to run slightly faster than java or labview.
I think that you guys should stick with java personally, because you know it and you will only have to deal with minor changes instead of learning a whole new syntax plus changes during the season.
$ arm-frc-linux-gnueabi-gcc-4.9 -v
Using built-in specs.
COLLECT_GCC=arm-frc-linux-gnueabi-gcc-4.9
COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/arm-frc-linux-gnueabi/4.9.1/lto-wrapper
Target: arm-frc-linux-gnueabi
Configured with: /run/shm/pkg/toolchain-builder/deb/gcc-4.9.1/configure --build=x86_64-linux-gnu --prefix=/usr --includedir=‘/usr/include’ --mandir=‘/usr/share/man’ --infodir=‘/usr/share/info’ --sysconfdir=/etc --localstatedir=/var --libdir=‘/usr/lib/x86_64-linux-gnu’ --libexecdir=‘/usr/lib/x86_64-linux-gnu’ --disable-maintainer-mode --disable-dependency-tracking --enable-threads=posix --target=arm-frc-linux-gnueabi --with-arch=armv7-a --with-cpu=cortex-a9 --with-float=softfp --with-fpu=vfp --with-specs=‘%{save-temps: -fverbose-asm} %{funwind-tables|fno-unwind-tables|mabi=*|ffreestanding|nostdlib:;:-funwind-tables}’ --enable-languages=c,c++ --enable-shared --enable-lto --disable-nls --with-pkgversion=‘GCC for FRC’ --with-cloog --disable-multilib --disable-multiarch --prefix=/usr --with-sysroot=/usr/arm-frc-linux-gnueabi --enable-poison-system-directories --enable-plugin --with-system-zlib --disable-libmudflap --with-build-sysroot=/usr/arm-frc-linux-gnueabi --program-suffix=-4.9 --program-prefix=arm-frc-linux-gnueabi-
Thread model: posix
gcc version 4.9.1 (GCC for FRC)